>...
>Date: Fri, 18 Mar 2005 03:40:20 +0100
>From: mouss <[EMAIL PROTECTED]>
>...
>Subject: Re: Is this Received header correctly formatted?
>...
>
>List Mail User wrote:
>>>...
>>>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."
>>
>
>that says what should be inside, not in comments. or are you meaning
>that qmail's:
> Received: (from the network ...); ...
>is illegal?
>you might, but you'd better come with real arguments.
[end of history - start of actual response]
Actually, I have to admit, that without checking I usually just
assume qmail is wrong;) But in this case the "Received: (from the network"
(actually, all the examples from qmail a quick check showed, were of the form
"(invoked ...", but the argument is the same) is comformant because the format
for a "Received:" line is defined by:
RFC 2822 Section 3.6.7
"...
received = "Received:" name-val-list ";" date-time CRLF
name-val-list = [CFWS] [name-val-pair *(CFWS name-val-pair)]
..."
And the CFWS is exactly what Eric pointed to before as the case
where comments are allowed. What you seem to be missing is that a space
in the BNF is *not* white space, but just a delimiter. You need to check
what is in RFC 2234, as specifically mentioned in RFC2822 Section 1.2.2.
Whis is "white space" is always denoted as one of "WSP", or "LWSP" (RFC2234
Sections 4 and 6.1). RFC2822 Section 3.2.3 introduces "FWS" and "CWSP" for
the purposes of that document. Comments are allowed in headers whenever
"CWSP" is used in the BNF - The definition a comment (for RFC2822) is given
as:
RFC 2822 Section 3.2.3
"...
There are several places in this standard where comments and FWS may
be freely inserted. To accommodate that syntax, an additional token
for "CFWS" is defined for places where comments and/or FWS can occur.
However, where CFWS occurs in this standard, it MUST NOT be inserted
in such a way that any line of a folded header field is made up
entirely of WSP characters and nothing else.
FWS = ([*WSP CRLF] 1*WSP) / ; Folding white space
obs-FWS
...
comment = "(" *([FWS] ccontent) [FWS] ")"
CFWS = *([FWS] comment) (([FWS] comment) / FWS)
..."
Note that when a comment appears in part of "CFWS" it is required
to have parenthesis around it - again, so the "helo=watson1" clause which
started all of this mess is again, not valid. It does seem that a line
containing "(helo=watson1) [4.16.241.28]" would be legal, but would seem
to be violating the "spirit of the law" which says, (paraphrased) data not
derived from EHLO. Note, the parenthesis are required around comments (the
BNF specifies them as quoted literal characters as shown above).
Anyway the qmail case would be parsed as a received line with a
perfectly legal comment at the beginning of an otherwise empty "name-val-list"
and a required "date-time" at the end. Certainly not optimal, but legal (I
would want to see a "name-val-list" containing at least one "name-val-pair",
as it is of more interest than the comment of "invoked ..." in some fashion).
[more thread history below]
>
>
>> 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. Also, the
>> inclusion of the parenthesis seems to be incorrect for a bare literal; 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).
>>
>> Paul Shupak
>> [EMAIL PROTECTED]
>>
>
>
Paul Shupak
[EMAIL PROTECTED]
P.S. I noticed earlier (and you probably got an empty message I didn't mean
to send) that your provider sends email using the nonexistant hostname of
ouzoud.netoyen.net in the HELO/EHLO argument - this should be fixed. I
refuse mail (well, actually 450 it) when there is no reverse DNS - check
any AOL server for a good statement of why they do also (just telnet in to
read their explanation in the "sign-on" message).
