... Date: Thu, 17 Mar 2005 00:29:43 +0100 From: mouss <[EMAIL PROTECTED]> ... To: List Mail User <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Is this Received header correctly formatted? ...
List Mail User wrote:
In other words, lowercase is conformant. and your first point is not correct (though all the examples do show uppercase). However, you are completely correct that the "helo=" is flat out wrong,
why? it's inside a comment, no?
but with a slight
variation, and it becomes something like "(watson1 [4.16.241.28])" which is not only conformant, but is the the typical behavior or both sendmail and postfix.
except that here the situation is reversed.
while postfix and sendmail use "from heloname (client_namer [client_ip])", others such as qmail prefer "from client_name ([client_ip]) (helo heloname)" or other variants.
Mous,
You're correct about the reversal, I realized that *after* I sent the message. Also technically the area after the [client_ip] is not white space. Eric properly pointed out that the entire header field already has an assigned use already, and the comment in the definition states specifically not to use information from the HELO.
To requote:
"TCP-info = Address-literal / ( Domain FWS Address-literal ) ; Information derived by server from TCP connection ; not client EHLO."
Notice the definition does not use any specification for white space after
the address literal. The single "space" character does not count - The
notation uses that to delineate between atoms and/or tokens; There would have
to be a reference to either "FWS", "WSP" or maybe even "LWSP" might qualify;
But since none of those atoms are part of the definition, the area after the
literal and before the ')' does not qualify as white space. So the clause
"([4.16.241.28] helo=watson1)" seems to be clearly non-conformant.
ahem. the specs provide for comments, and don't restrict comments. so whatever is in between pars is ok. the specs even allow silly things linke Fr(foo)om. btw, unlike what a lot of people seem to think, rfc2821 is only a "standard track'.
Also, the
inclusion of the parenthesis seems to be incorrect for a bare literal;
as far as this is in comments, there is no issue. so Receieved: from foo (whatever is here) is ok.
They
are only specified for the second alternative with both the "Domain" and "Address-literals". I do agree that is it not enough of an error that mail should be refused on that basis alone, but if a server were to do so, it would be within its prerogative (and seemingly legal to do so).
as far as I can see, the std allows for a lot of received stuff. the std even manages to create a notion of domain that is not compatible with a dns domain. after all, smtp has apparently been defined by sendmail....
