919953 - TB messes up RFC822 groups (named lists with semicolon, e.g. testlist: [e-mail], [e-mail]; )

Status: NEW

(Thunderbird :: Message Compose Window, defect)

Description

[u166595]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20100101 Firefox/23.0 (Beta/Release)
Build ID: 20130814063812

Steps to reproduce:

Case 1) Send a message to:
   testlist:[e-mail],[e-mail];

Case 2) Send a message to:
   testlist: [e-mail], [e-mail];

Both cases tested with 2 different smtp servers.


Actual results:

Case 1)
The first address yields an odd reject:
    [e-mail] user unknown
The second address is delivered, but in the To: line both addresses are exposed and the trailing ';' is missing:
    To: testlist:[e-mail], [e-mail]
  
Case 2)
The first address yields an odd reject:
    <testlist:[e-mail]> user unknown
The second address again is delivered, but in the To: line both addresses are exposed, the trailing ';' is missing, and the first address is mangled.
    To: "testlist: name1"@foo.com, [e-mail]



Expected results:

1) The message should have been delivered unmangled to all recipients.
2) LWSP should not make any difference.
3) The To: line should have been:
    To: testlist:;
    This hiding of addresses is not required by RFC822, but determined by the receiving mail agent. The dropping of the trailing ';' though causes it to not recognize it as a named list.

Comment 1

[Thomas D. (:thomas8)]

Piet, thanks for reporting. It's very possible TB exhibits these problems as described, even wrong spaces in normal addresses cause failure and should not.

However, I'd consider named lists an edge case which is probably not used by many users...

As TB is maintained by volunteers, you are very welcome to provide a patch... ;)

Comment 2

[Thomas D. (:thomas8)]

Piet, thanks for reporting. It's very possible TB exhibits these problems as described, even wrong spaces in normal addresses cause failure and should not.

However, I'd consider named lists an edge case which is probably not used by many users...

As TB is maintained by volunteers, you are very welcome to provide a patch... ;)

Comment 3

[Wayne Mery (:wsmwk)]

duplicate of bug 83521?

Comment 4

[u166595]

(In reply to Wayne Mery (:wsmwk) from comment #3)
> duplicate of bug 83521?

No.
83521 is about "lists" in the Address Book, and RFC822 groups / named lists as a possible way to implement them.
Even so, 919953 is related and may well have a common source:

Put an entry named "test" in your Address Book containing:
mylist:[e-mail],[e-mail],[e-mail];
Click on that contact to compose a new message.
Its header is nog pre-filled with:
To: mylist:[e-mail]
To: [e-mail]
To: [e-mail]

Now change the entry into:
mylist: [e-mail], [e-mail], [e-mail];
The header pre-fill now gets:
To: mylist: [e-mail]
To: [e-mail]
To: [e-mail]

This explains both Case 1) and Case 2) in my initial report. But I don't use the Address Book, so the bug must be in a common part of the header/address handling.

And then, apart from this, there is really no reason why it shouldn't be possible to put an RFC 822 group / named list in the Address Book and have it appear *as such* in the pre-filled header.

Comment 5

[Thomas D. (:thomas8)]

(In reply to Piet Beertema from comment #4)
> (In reply to Wayne Mery (:wsmwk) from comment #3)
> > duplicate of bug 83521?
> 
> No.
> 83521 is about "lists" in the Address Book, and RFC822 groups / named lists
> as a possible way to implement them.

+1. This bug 919953 is a bug in its own right (unless earlier reports can be found, I didn't see any). RFC822 groups as recipients are completely disfunctional in TB composition, even for the most basic case of comment 0. Might be fallout from bug 242693.

Comment 6

[u166595]

(In reply to Thomas D. from comment #5)
> RFC822 groups as recipients are completely disfunctional in TB composition,
> even for the most basic case of comment 0. Might be fallout from bug 242693.

I'm *very* suspicious about the latter. That "bug" really scares me. Or rather the approach.
When we're talking about Thunderbird, we're talking about an *Internet mail* client. That's
software governed solely by *Internet standards* (RFC822/RFC2822 in this case, *not* by M$
idiosyncracies. Period. Break the standards, and you're breaking the Internet.

Now of course there's Postel's law. So you might try to be liberal and find a way to cope
with M$ idiosyncracies. But the result *must* be fully RFC-compliant. But in this case I
suspect that the address parser may have been made a bit too smart, resulting in breaking
RFC822 groups / named lists.

Comment 7

[Joshua Cranmer [:jcranmer]]

The header fields in the compose window are not intended to be literal RFC 5322/RFC 6532 strings. Thus functionality of listing group names inside those fields is not expected to work.

(In reply to Piet Beertema from comment #6)
> When we're talking about Thunderbird, we're talking about an *Internet mail*
> client. That's
> software governed solely by *Internet standards* (RFC822/RFC2822 in this
> case, *not* by M$
> idiosyncracies. Period. Break the standards, and you're breaking the
> Internet.

Except half the email standards bear little-to-no-reflection in reality. Standards purity is all nice and well, but I'd rather have emails that other clients can view than emails than ones that implement the standards to the letter.

(And if you're going to try to take the high ground in a standards dispute, please be up-to-date on the correct standards.)