why in the second message i can not see "for <em...@address.com>; " information ? it is not mandatory ?
thanks of your answers
Received: from mx4.messagingengine.com ([10.202.2.203]) by compute1.internal (LMTPProxy); Tue, 01 Jul 2008 14:11:18 -0400 Received: from spock.galacsys.net (mx2.galacsys.net [88.191.250.28]) by mx4.messagingengine.com (Postfix) with ESMTP id AA1F3B283 for <x...@fastmail.fm>; Tue, 1 Jul 2008 14:11:16 -0400 (EDT) Received: from ns30465.ovh.net (ns1.bourges.biz [213.186.46.163]) by spock.galacsys.net (Postfix) with SMTP id 26D81450D5 for <destro...@willemijns.com>; Tue, 1 Jul 2008 20:11:15 +0200 (CEST)
*************************************************
Received: from mx6.messagingengine.com ([10.202.2.205]) by compute1.internal (LMTPProxy); Tue, 01 Jul 2008 14:15:40 -0400 Received: from mccoy.galacsys.net (mx3.galacsys.net [217.24.89.4]) by mx6.messagingengine.com (Postfix) with ESMTP id B067C584A1; Tue, 1 Jul 2008 14:15:35 -0400 (EDT) Received: from mail.azeronline.com (mail.azeronline.com [62.217.132.62]) by mccoy.galacsys.net (Postfix) with ESMTP id 1812022834; Tue, 1 Jul 2008 20:15:30 +0200 (CEST) Received: from [62.217.139.79] (HELO azeronline.com) by mail.azeronline.com (CommuniGate Pro SMTP 5.1.13) with SMTP id 1069888; Tue, 01 Jul 2008 23:14:50 -0400 ---
"sebast...@willemijns.com" <sebast...@willemijns.com> writes: >why in the second message i can not see "for <em...@address.com>; " >information ? >it is not mandatory ?
No, it is not mandatory.
Some smtp servers omit that information if there are multiple recipients (to protect privacy of "bcc:" addresses).
> why in the second message i can not see "for <em...@address.com>; " > information ? > it is not mandatory ?
> thanks of your answers
"For" is not mandatory. It is clearly optional, just like "via", "with", and "id" - which must occur in their specified order.
"From" and "By" clauses are mandatory under SMTP, where there should be a "with *SMTP*" indicating the flavor of SMTP used. RFC 2821 tells us this. Therefore, if a "with SMTP" clause is present and "from" or "by" is absent, the message is syntactically incorrect. RFC 2822 warns that messages must not be rejected for unrecognized "Received:" header fields (especially if sent by other protocols), but in this strict example, RFC 2821 applies and indicates that these fields are required, so I interpret that as meaning that I may reject the malformed message - but only where the header itself declares that 2821's rules specifically apply by including the "with *SMTP*" clause.
However, if the transfer is NOT using a version of SMTP, RFC 2822 tells us that the only components in a "Received:" header field that are mandatory are the semicolon followed by the transaction time (in the format specified). Any string of characters excluding an unquoted semicolon may appear before the required semicolon.
Remember that without the "with" clause, you cannot tell if the other transfers were SMTP or not. You only know that the transfer into YOUR server is or isn't - but there will be no received header for that - as your server is the one that adds it and you haven't necessarily done that yet.
On 2 juil, 06:53, Neil W Rickert <rickert...@cs.niu.edu> wrote:
> "sebast...@willemijns.com" <sebast...@willemijns.com> writes: > >why in the second message i can not see "for <em...@address.com>; " > >information ?
> Some smtp servers omit that information if there are multiple > recipients (to protect privacy of "bcc:" addresses).
i'm surprising of this answer about privacy... it is easy to parse *our* address on the field ?!
On 2 juil, 08:22, "D. Stussy" <s...@bde-arc.ampr.org> wrote:
> However, if the transfer is NOT using a version of SMTP, RFC 2822 tells us > that the only components in a "Received:" header field that are mandatory > are the semicolon followed by the transaction time (in the format > specified). Any string of characters excluding an unquoted semicolon may > appear before the required semicolon.
thanks of your (long) answer
if i well understood, if i can not see my "for" field in a postfix "received :" field it is because message was sent by a gateway...
On Sat, 05 Jul 2008 12:45:28 -0700, sebast...@willemijns.com wrote: > On 2 juil, 06:53, Neil W Rickert <rickert...@cs.niu.edu> wrote: >> "sebast...@willemijns.com" <sebast...@willemijns.com> writes: >> >why in the second message i can not see "for <em...@address.com>; " >> >information ?
>> Some smtp servers omit that information if there are multiple >> recipients (to protect privacy of "bcc:" addresses).
> i'm surprising of this answer about privacy... it is easy to parse > *our* address on the field ?!
In many cases the CC: may simply say "undisclosed-recipients:" and the BCC: line (if it appears at all) will say that too. After all, what's the use of BCC (which stands for Blind CC) if it then listds the names of BCC recipients for everybody to see.
Some MTAs and mail list servers set the To: header to "undisclosed-recipients:" as well, so if you're analysing or archiving received mail then your analysis or archiving software must deal with this gracefully and not die. Mine replaces "undisclosed-recipients:" in To:, CC: or BCC: headers with my address since I did receive the message and JavaMail does not think "undisclosed-recipients:" is a valid address.
-- martin@ | Martin Gregorie gregorie. | org | Zappa fan & glider pilot
On Sun, 06 Jul 2008 19:32:19 +0100, Martin Gregorie <martin@see_sig_for_address.invalid> wrote:
...
> In many cases the CC: may simply say "undisclosed-recipients:"
Shouldn't that be "undisclosed-recipients:;" ?
> and the BCC: line (if it appears at all) will say that too. After all, > what's the use of BCC (which stands for Blind CC) if it then listds the > names of BCC recipients for everybody to see.
> Some MTAs and mail list servers set the To: header to > "undisclosed-recipients:" as well, so if you're analysing or archiving > received mail then your analysis or archiving software must deal with this > gracefully and not die. Mine replaces "undisclosed-recipients:" in To:, > CC: or BCC: headers with my address since I did receive the message and > JavaMail does not think "undisclosed-recipients:" is a valid > address.
Which means JavaMail (whatever that is; hopefully it's not part of Java) is seriously broken; this form is valid and even appears in several examples in RFC 2822.
(You seem to know that, but I thought it should be mentioned more explicitly. When someone violates the RFCs we should say so, clearly.)
My fixer-upper deals with them all. I don't think there are any others - if there are I haven't seen them. Javamail is picky about the list separator too and would barf at your example because it doesn't like ';', and insisting on ',' within a list and nothing after the last address.
> Which means JavaMail (whatever that is; hopefully it's not part of Java)
Its one of Sun's addon packages.
> is seriously broken; this form is valid and even appears in several > examples in RFC 2822.
That's quite possible. I didn't check the RFC about this because the issue for making my archiver work is one of tweaking its input into something that JavaMail's rather intolerant parser likes rather than sticking to the RFC. My fixer's actions are entirely empirical, derived from analysing rejected mail and, if the fault is common enough, adding a tweak for it to the fixer.
> (You seem to know that, but I thought it should be mentioned more > explicitly. When someone violates the RFCs we should say so, clearly.)
Hmmm, but do they listen?
M$ is responsible for one of those three variants (I think the 3rd may be theirs) and for allowing ';' to separate addresses under all three headers, but they probably think these are 'features' that gives them user lock-in.
JavaMail was open sourced in 2006 but, as it hasn't been since the start of 2007, it looks like nobody has been sufficiently motivated to change it yet.
-- martin@ | Martin Gregorie gregorie. | org | Zappa fan & glider pilot
> My fixer-upper deals with them all. I don't think there are any others - > if there are I haven't seen them. Javamail is picky about the list > separator too and would barf at your example because it doesn't like ';', > and insisting on ',' within a list and nothing after the last address.
I was more thinking like "what's a valid, empty group address?" rather than "what is the official thing to put in To: in an all-Bcc:ed mail?"[1]. A quick glance at RFC 2822 suggests that the semicolon *must* be there: it is part of the more general group address form
group-name : mailbox1, mailbox2, ... mailboxN ;
I guess a Google search would tell us more.
/Jorgen
[1] But now that you mention it, it is useful for the recipient to be able to tell the difference between "I was Bcc:ed on this mail" and "I got this mail because I am on a mailing list".
>> My fixer-upper deals with them all. I don't think there are any others - >> if there are I haven't seen them. Javamail is picky about the list >> separator too and would barf at your example because it doesn't like ';', >> and insisting on ',' within a list and nothing after the last address.
>I was more thinking like "what's a valid, empty group address?" rather >than "what is the official thing to put in To: in an all-Bcc:ed >mail?"[1]. A quick glance at RFC 2822 suggests that the semicolon *must* >be there: it is part of the more general group address form
> group-name : mailbox1, mailbox2, ... mailboxN ;
Yes indeed, the semicolon is part of the "group address" syntax, it's not a list separator as in the broken M$ form of multi-address lists. The "group-name" part can be anything of course, undisclosed-recipients (or some variant thereof) is just a convention commonly used when the mailbox list is empty. It must follow the syntax rules for a "phrase" though, i.e. quoting is required in many cases (e.g. if there is internal whitespace - the third form above is thus not allowed, it must be "Undisclosed recipients").
> >> My fixer-upper deals with them all. I don't think there are any others - > >> if there are I haven't seen them. Javamail is picky about the list > >> separator too and would barf at your example because it doesn't like ';', > >> and insisting on ',' within a list and nothing after the last address.
> >I was more thinking like "what's a valid, empty group address?" rather > >than "what is the official thing to put in To: in an all-Bcc:ed > >mail?"[1]. A quick glance at RFC 2822 suggests that the semicolon *must* > >be there: it is part of the more general group address form
> Yes indeed, the semicolon is part of the "group address" syntax, it's > not a list separator as in the broken M$ form of multi-address lists. > The "group-name" part can be anything of course, undisclosed-recipients > (or some variant thereof) is just a convention commonly used when the > mailbox list is empty. It must follow the syntax rules for a "phrase" > though, i.e. quoting is required in many cases (e.g. if there is > internal whitespace - the third form above is thus not allowed, it must > be "Undisclosed recipients").
Undisclosed recipients
is allowed (although syntax is unclear).
Undisclosed.Recipients
is not allowed (or is not allowed to be generated, but must be able to parse.)
White space, including folding white space, and comments can be inserted between many of the tokens of fields. Taking the example from A.1.3, white space and comments can be inserted into all of the fields.
---- From: Pete(A wonderful \) chap) <pete(his account)@silly.test(his host)> To:A Group(Some people) :Chris Jones <c@(Chris's host.)public.example>, j...@example.org, John <j...@one.test> (my dear friend); (the end of the group) Cc:(Empty list)(start)Undisclosed recipients :(nobody(that I know)) ; Date: Thu, 13 Feb 1969 23:32 -0330 (Newfoundland Time) Message-ID: <testabcd.1...@silly.test>
Testing. ----
The above example is aesthetically displeasing, but perfectly legal. Note particularly (1) the comments in the "From:" field (including one that has a ")" character appearing as part of a quoted-pair); (2) the white space absent after the ":" in the "To:" field as well as the comment
