LCC displays first member in To: field
J. O'Connell
I've been using Pine for years, and now Alpine, and am now finding
problems with Alpine's 'LCC' address function.
Description:
1 Blank 'To' line; GroupName in 'lcc'.
2. GroupName expands, all members listed, and Group description now in
'To' field ... *with* the Full Name of the first member of the group.
This person's name shows up in the 'to' field in every recipient's
inbox.
Here's an example of the result:
To :"St. Louis County Green Team (2009-2010) -- Abigail O'Niell": ;
'Abigail O'Neill' is, indeed, a member of the twenty-two member list,
and her name comes up first alphabetically.
My questions are: A) why is her name concatenated to the 'To' field, and
B) how do I have it not show up?
Help & suggestions are appreciated.
Thanks!
-Fionn
Lucas Levrel
> 1 Blank 'To' line; GroupName in 'lcc'.
>
> 2. GroupName expands, all members listed, and Group description now in
> 'To' field ... *with* the Full Name of the first member of the group.
> This person's name shows up in the 'to' field in every recipient's
> inbox.
>
> Here's an example of the result:
>
> To :"St. Louis County Green Team (2009-2010) -- Abigail O'Niell": ;
>
> 'Abigail O'Neill' is, indeed, a member of the twenty-two member list,
> and her name comes up first alphabetically.
>
> My questions are: A) why is her name concatenated to the 'To' field, and
> B) how do I have it not show up?
Hi,
I've got the same problem with Pine.
A) I guess this is linked to the behaviour of the To: field which is
similar (and a bit annoying there also): If you put the group name there,
the list is expanded and the group name is concatenated with the first
member's name. In the To: case it seems Pine doesn't know how to---or
cannot per the SMTP standard---insert a name without address into the list
of recipients, something like: "groupname"<>, "person1"<f...@bar.com>,
etc., so it concats "groupname" with "person1".
B) I edit the field by hand (in the To: case, removing the group name, in
the Lcc: case, removing the person's name).
--
LL
J. O'Connell
It seems that the SMTP standard can handle the case of 'a name without
an address' -- witness the format that includes the ": ;" (Colon, space,
semicolon) at the "To:" EOL.
I suspect that the problem lies with Pine and Alpines' handling of names
within double-quotes ("); I've noticed that if the GroupName and the
FirstMemberName are both within double-quotes, then the two fields are
merged into one; e.g.:
"Field1","Field2" ==> "Field1 Field2"
And these fields are rendered within double-quotes when there is a
non-alphanumeric character in the name -- and this includes apostrophes,
commas, full stops, hyphens, and braces.
Conversely, this field concatenation effect does *not* occur if these
non-alphanumeric characters are not present.
>
> B) I edit the field by hand (in the To: case, removing the group name,
> in the Lcc: case, removing the person's name).
Sadly, I do the same; I catch much grief from 'Abigail' when her name
is inadvertently posted publicly.
-Fionn
Lucas Levrel
> I suspect that the problem lies with Pine and Alpines' handling of names
> within double-quotes ("); I've noticed that if the GroupName and the
> FirstMemberName are both within double-quotes, then the two fields are
> merged into one; e.g.:
>
> "Field1","Field2" ==> "Field1 Field2"
>
> And these fields are rendered within double-quotes when there is a
> non-alphanumeric character in the name -- and this includes apostrophes,
> commas, full stops, hyphens, and braces.
>
> Conversely, this field concatenation effect does *not* occur if these
> non-alphanumeric characters are not present.
Crazily enough, I cannot reproduce any problem when testing! I would have
sweared seeing the same problem as you, but now when I test, GroupName
appears alone in the To: field, whereas it gets concatenated with the
first member's name in the Lcc: field!
I've tested with and without: non-ASCII letters (accents), hyphen,
apostrophe. And with single or double field addressbook entries (John Doe
or Doe, John).
Maybe is there an interaction with character set or coding options? Here
are the relevant options in my .pinerc:
feature-list=
enable-8bit-esmtp-negotiation,
no-disable-charset-conversions,
no-pass-control-characters-as-is,
enable-8bit-nntp-posting,
downgrade-multipart-to-text,
character-set=utf-8
assumed-charset=
--
LL
J. O'Connell
> Crazily enough, I cannot reproduce any problem when testing! I would
> have sweared seeing the same problem as you, but now when I test,
> GroupName appears alone in the To: field, whereas it gets concatenated
> with the first member's name in the Lcc: field!
>
> I've tested with and without: non-ASCII letters (accents), hyphen,
> apostrophe. And with single or double field addressbook entries (John
> Doe or Doe, John).
>
> Maybe is there an interaction with character set or coding options?
> Here are the relevant options in my .pinerc:
> feature-list=
> enable-8bit-esmtp-negotiation,
> no-disable-charset-conversions,
> no-pass-control-characters-as-is,
> enable-8bit-nntp-posting,
> downgrade-multipart-to-text,
> character-set=utf-8
> assumed-charset=
I've been testing, and have identified the concatenation effect when the
GroupName has (hyphens, aphostrophes, accents, or non-ASCII characters).
If the GroupName does not have these characters, it does not get
reproduced.
I've also tested with Groups made of multiple sub-Groups, and in these
cases multiple GroupNames get expanded in the 'To:' field. An example:
To: "Student Body -- Class 1 -- John Doe": ;
Where 'John Doe' would be the first member of 'Class 1'. Members of
'Class 2' or 'Class 3' (components of the 'Student Body' group) would
not appear in the line.
A point of note: all my individual member names are in 'double field
addressbook entry' (as you described it), ordered by last-name first
(LastName, comma, FirstName). These get re-arranged by *pine in the
visible To:/CC:/BCC:/LCC: field (FirstName, space, LastName). Does this
contribute to the problem? I do not know.
Reproducability:
1. I cannot consistently reproduce the problem with 'New' compositions
(Keystroke 'C'). I need to re-check the non-ASCII character in the
GroupName issue to confirm.
2. The issue is reproducable when repyling (Keystroke 'R') to an e-mail,
and adding the GroupName to any of the To:/CC:.... fields.
So, as it stands, I'm continuing to work the issue, and am very glad to
know I'm not the only user bothered by this. I wonder how we might
escalate this to the developers. Do we know if they follow this
Newsgroup?
-Fionn
Lucas Levrel
> 2. The issue is reproducable when repyling (Keystroke 'R') to an e-mail,
> and adding the GroupName to any of the To:/CC:.... fields.
My previous tests were all done with Compose. New tests with Reply didn't
show up the problem either [my test groupname is Test-zé'rø which should
be enough ;-)]... at first sight. But there are really weird things
happening:
- Displaying your message, I hit R then R (as if I wanted to write to you
instead of to the newsgroup).
-> If I add the group nickname ("test") to Lcc:, the list is expanded
there, nothing is added to To: (where your name already is).
-> If I add it to To:, the list is expanded there, with the groupname
concatenated to the first member name; nothing really annoying since
names are public in To: anyway. *Now If I kill lines corresponding to
the test group and leave your address, then add the group nick to Lcc:,
the list is expanded there, and _your_ address in To: is killed and
replaced by the groupname (alone)!*
-> I could swear that once, during my tests, I saw the exact same thing
but with the groupname concatenated with the first member name. But I
cannot reproduce it. Maybe is there an interplay with Postponing (e.g.
Pine doesn't fill Fcc: when I reply, unless I postpone & resume, in
which case it puts Fcc: sent-mail).
> So, as it stands, I'm continuing to work the issue, and am very glad to
> know I'm not the only user bothered by this.
I'm glad you're glad! :-D
> I wonder how we might escalate this to the developers. Do we know if
> they follow this Newsgroup?
I don't know, but I think that should not be a problem from Alpine's
webpage. They'll probably want a reliable testcase, but I wonder whether
we'll manage to make one before we become crazy!
--
LL
LC's No-Spam Newsreading account
> Le 17 octobre 2009, J. O'Connell a écrit :
>
>> 1 Blank 'To' line; GroupName in 'lcc'.
>> 2. GroupName expands, all members listed, and Group description now in
>> 'To' field ... *with* the Full Name of the first member of the group.
>> My questions are: A) why is her name concatenated to the 'To' field, and
>> B) how do I have it not show up?
Does not happen (or at least not usually) to me. Usually I go to rich
field mode (^R), and enter a nickname of a list in Lcc. At this stage I
see the list full name, some dashes, and the name of the first member.
But as soon as I toggle ^R again, I see only the list full name in To
(with a semicolon at the end).
I think that's handy because having a descriptive list name will help
the recipients (otherwise I'd just use Bcc instead of Lcc).
Perhaps the behaviour you quote is linked to the fact your nickname has
no descriptive name ?
--
----------------------------------------------------------------------
nos...@mi.iasf.cnr.it is a newsreading account used by more persons to
avoid unwanted spam. Any mail returning to this address will be rejected.
Users can disclose their e-mail address in the article if they wish so.
J. O'Connell
> On Mon, 19 Oct 2009, Lucas Levrel wrote:
>> Le 17 octobre 2009, J. O'Connell a écrit :
>>
>>> 1 Blank 'To' line; GroupName in 'lcc'.
>>> 2. GroupName expands, all members listed, and Group description now in
>>> 'To' field ... *with* the Full Name of the first member of the group.
>
>>> My questions are: A) why is her name concatenated to the 'To' field, and
>>> B) how do I have it not show up?
>
> Does not happen (or at least not usually) to me. Usually I go to rich field
> mode (^R), and enter a nickname of a list in Lcc. At this stage I see the
> list full name, some dashes, and the name of the first member.
>
> But as soon as I toggle ^R again, I see only the list full name in To (with a
> semicolon at the end).
>
> I think that's handy because having a descriptive list name will help the
> recipients (otherwise I'd just use Bcc instead of Lcc).
>
> Perhaps the behaviour you quote is linked to the fact your nickname has no
> descriptive name ?
No; the nickname (called 'GroupName' in the OP) has a descriptive name,
which is the 'GroupName expands' in item #2 in the OP. The nickname is
replaced by the Descriptive name, dashes, and then the first member name
of the group. Please refer to the example cited in the original post to
see what goes on.
We appear to have different results when we toggle ^R:
Like you, we see the list full name, some dashes, and the name of the
first member.
"But as soon as I toggle ^R again, I see only the list full name in To
(with a semicolon at the end)." -- and here is where our results
diverge: In our case, the list full name appears, but the name of the
first member does *not* disappear; it remains in the 'To' field.
As indicated earlier in the thread, it appears to have something to do
with entries using Double-quotes (those entries with non-alphanumeric
characters, requiring double-quotes for the field).
When you say 'Does not happen (or at least not usually) to me', could
you describe when it does -- unusually -- happen?
Regards,
Fionn
Lucas Levrel
> As indicated earlier in the thread, it appears to have something to do
> with entries using Double-quotes (those entries with non-alphanumeric
> characters, requiring double-quotes for the field).
Uh-oh, I forgot this in my tests. I never used double quotes for such
chars, and never got problems with them. I have just tested a quoted
"Group Name" together with a quoted, two-field member name ("Last",
"First"), and Pine is having big trouble expanding this, it even fails to
assemble the member name into "First Last". (Then I'm unable to leave the
Lcc: field because it complains about unexpected chars.)
Also, I have the Lcc: field in my default-composer-headers.
You may want to try these ways.
--
LL
J. O'Connell
> Le 22 octobre 2009, J. O'Connell a écrit :
>
>> As indicated earlier in the thread, it appears to have something to do
>> with entries using Double-quotes (those entries with non-alphanumeric
>> characters, requiring double-quotes for the field).
>
> Uh-oh, I forgot this in my tests. I never used double quotes for such
> chars, and never got problems with them. I have just tested a quoted
> "Group Name" together with a quoted, two-field member name ("Last",
> "First"), and Pine is having big trouble expanding this, it even fails to
> assemble the member name into "First Last". (Then I'm unable to leave
> the Lcc: field because it complains about unexpected chars.)
I apologize that what I wrote wasn't clear; I *do NOT* type the
'double-quotes' myself. The double-quotes are inserted around entries
with non-[0-9a-zA-Z] characters by the *pine program itself. Typing
double-quotes would be expected to preserve the member name as-is, and
would not change the member name.
Use of double-quotes forces the field to be literal, which prevents pine
from acting on it. D-Q is rightly an 'unexpected character'.
That behavior you describe is expected.
-Fionn
Beartooth
[....]
> I apologize that what I wrote wasn't clear; I *do NOT* type the
> 'double-quotes' myself. The double-quotes are inserted around entries
> with non-[0-9a-zA-Z] characters by the *pine program itself. Typing
> double-quotes would be expected to preserve the member name as-is, and
> would not change the member name.
>
> Use of double-quotes forces the field to be literal, which prevents pine
> from acting on it. D-Q is rightly an 'unexpected character'.
>
> That behavior you describe is expected.
Whenever Pine or Alpine puts quotes into any .addressbook entry,
I edit them out. You can. Maybe it'll help.
--
Beartooth Staffwright, Neo-Redneck Not Quite Clueless Power User
I have precious (very precious!) little idea where up is.
J. O'Connell
> Whenever Pine or Alpine puts quotes into any .addressbook entry,
> I edit them out. You can. Maybe it'll help.
None of the .addressbook entries have quotes around them; they are added
by pine or alpine when the message is created / when the "To" or "BCC"
fields are populated -- "on the fly".
If the group memberlist has dozens -- or even hundreds -- entries,
manually editing out the quotes is prohibitive, especially if they're
not present in any .addressbook entry.
You'll see we discussed this effect earlier in the thread.
-Fionn
Lucas Levrel
> None of the .addressbook entries have quotes around them; they are added
> by pine or alpine when the message is created / when the "To" or "BCC"
> fields are populated -- "on the fly".
Mine doesn't add any double quotes. What are your charset and related
config options, so that we can compare?
--
LL
J. O'Connell
> Mine doesn't add any double quotes. What are your charset and related
> config options, so that we can compare?
Charset is UTF-8... what else would you like to see?
-Fionn
Lucas Levrel
Those settings I mentionned on October 20th:
> Maybe is there an interaction with character set or coding options? Here
> are the relevant options in my .pinerc:
> feature-list=
> enable-8bit-esmtp-negotiation,
> no-disable-charset-conversions,
> no-pass-control-characters-as-is,
> enable-8bit-nntp-posting,
> downgrade-multipart-to-text,
> character-set=utf-8
> assumed-charset=
--
LL
J. O'Connell
mailing-list sponsored by the University of Washington -- the people who
developed pine and alpine.
The response I got was that the (LCC / first membername) issue was a
problem in the last version of pine, and wasn't corrected in the code
port/rewrite for pine. It does, in fact, appear to be a bug.
It may or may not get corrected in the next revision/update.
See here:
http://mailman2.u.washington.edu/pipermail/alpine-info/2009-October/002700.html
-Fionn
Lucas Levrel
> http://mailman2.u.washington.edu/pipermail/alpine-info/2009-October/002700.html
Thanks! Now we know exactly what to do to reproduce and avoid the bug.
--
LL