At 18:38 +0200 on 06/12/2007, Arnt Gulbrandsen wrote about 2821bis:
received: ... for clause:
Hi,
The 'for' production is incorrect as it stands. "Received: .... for
tony(_at_)att(_dot_)comtony@att.com; ..." is legal according to 2821. Oops.
There are 2-3 ways out of this:
- constrain 'for' to one address
- introduce a separator:
- either FWS
- or "," FWS.
My preference is to constrain it to one address. I cannot remember
seeing production softwaret that inserts multiple addresses on
purpose, so IMO this can be classified as an unused feature and
dropped. (I checked 280k received fields just now and found none.)
Arnt
The rules as implemented (so far as all mail that I've received that
has a "for" clause) SEEMS to be that the "for address" is optional in
the case where there is ONE RCPT-TO envelope command and suppressed
when more than one RCPT-TO is supplied (which serves as a privacy
protection in that Bcc and mailing-list echoed messages that are
handed off to an SMTP Server with more than one addressee being
handled by that server will not expose the other addressees in the
Received headers of the POP/IMAP cloned copies). IOW: The a "for"
clause with more than one address is not valid in implementations.
OTOH - I have no problem with an implementation that once it
recognizes that it is supporting the ultimate destination domain,
either clones a multi-RCPT-TO message and inserts the correct
single-address "for" clause into each cloned copy OR does the
insertion when it does final delivery into a POP/IMAP mailbox
(assuming a Mail Box implementation where each mailbox is a private
store and not one that is linked to a common store which has a common
copy that gets deleted when the share count on the message goes to 0).