You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Loren Wilton <lw...@earthlink.net> on 2005/03/15 23:36:36 UTC
Is this Received header correctly formatted?
Received: from ar39.lsanca2-4.16.241.28.lsanca2.elnk.dsl.genuity.net
([4.16.241.28] helo=watson1)
by pop-a065d23.pas.sa.earthlink.net with smtp (Exim 3.33 #1)
id 1DBKRe-0000Kp-00; Tue, 15 Mar 2005 14:23:22 -0800
1) Is "stmp" in lower case valid, or should it have been STMP?
2) Is it valid to have the (Exim etc) stuff between 'stmp' and 'id'?
3) Anything else that may be off the mark?
Thanks,
Loren
Re: Is this Received header correctly formatted?
Posted by jdow <jd...@earthlink.net>.
From: "mouss" <us...@free.fr>
> Eric A. Hall wrote:
>
> >>
> >> Huh? The helo= stuff is inside the parenthesis. Perhaps I am missing
> >> something but your point 3 seems to conflicewith your point 2.
> >
> >
> > comments are only allowed where whitespace occurs
> >
>
> can you give you me the line num in the rfc?
>
> and even then, the original thing was:
> Received: from ar39.lsanca2-4.16.241.28.lsanca2.elnk.dsl.genuity.net
> ([4.16.241.28] helo=watson1)
> and here helo=watson1 is inside parens, and with withespace (before and
> after the parens). or am I missing something?
It IS Microsoft. I know that for certain. That machine is sitting about
10' to the East of me at this moment. My Received: header is will be
a similar format with "kittycat" as the helo. These are the computer
names on the local network isolated from the outside network by a Linux
firewall.
I am *NOT* about to rename these machines by the incomprehensible,
impossible to type from memory, and changeable name assigned to the
firewall interface.
I do NOT run a mail server for sending mail to the Internet on the
firewall machine. I do not, at this time, intend to. If we get a static
IP I might consider firing up a suitably screwed down Postfix for direct
incoming and outgoing email rather than the fetchmail configuration in
use at the moment.
While I fully realize that Microsoft is well known to "embrace and
extend" otherwise known as screw-up common standards for their own
incomprehensible reasons. (Most often it's probably some jerk genius
programming it who might declare, "Gee, I didn't think of that!" An
example of that is the means by which I, were I a malware author,
could render your machine mysteriously unbootable in anything but
safe-mode simply because Microsoft did not think of the consequences
of a change they put into SP2. A product I make happened to trigger
this defect. I had to find a way around it.) Anyway, the point of
this is that denying that format will deny a very large proportion
of mail that is from Outlook Express users.
Personally, I don't give a fleeking furglemonk whether you do or not.
I'm simply telling you what the facts of the situation are so that
you can make your own determination whether you want to block email
from a VERY large segment of the legitimate email crossing the net
today. Then you can take responsibility for lost or rejected email
for yourself. (If you have customers involved be aware this may
constitute a liability situation for you personally and your
company.)
{^_^} Joanne
PS: The actual firewall machine is imaginatively named "it".
If you dig in the headers enough maybe you can even figure out
the internal network particulars. It is NOT going to change
because somebody is needlessly particular about header formats.
Re: Is this Received header correctly formatted?
Posted by "Eric A. Hall" <eh...@ehsco.com>.
mouss wrote:
> Eric A. Hall wrote:
>
>>> Huh? The helo= stuff is inside the parenthesis. Perhaps I am missing
>>> something but your point 3 seems to conflicewith your point 2.
>>
>> comments are only allowed where whitespace occurs
>
> can you give you me the line num in the rfc?
It's actually somewhat stricter than that, and actually says that
comments can only be used where folding would occur (that's a
hyper-techinical but accurate reading; see the robustness principle).
Here is what rfc2822 says:
3.2.3. Folding white space and comments
[...]
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
ctext = NO-WS-CTL / ; Non white space controls
%d33-39 / ; The rest of the US-ASCII
%d42-91 / ; characters not including "(",
%d93-126 ; ")", or "\"
ccontent = ctext / quoted-pair / comment
comment = "(" *([FWS] ccontent) [FWS] ")"
CFWS = *([FWS] comment) (([FWS] comment) / FWS)
Throughout this standard, where FWS (the folding white space token)
appears, it indicates a place where header folding, as discussed in
section 2.2.3, may take place. Wherever header folding appears in a
message (that is, a header field body containing a CRLF followed by
any WSP), header unfolding (removal of the CRLF) is performed before
any further lexical analysis is performed on that header field
according to this standard. That is to say, any CRLF that appears in
FWS is semantically "invisible."
A comment is normally used in a structured field body to provide some
human readable informational text. Since a comment is allowed to
contain FWS, folding is permitted within the comment. Also note that
since quoted-pair is allowed in a comment, the parentheses and
backslash characters may appear in a comment so long as they appear
as a quoted-pair. Semantically, the enclosing parentheses are not
part of the comment; the comment is what is contained between the two
parentheses. As stated earlier, the "\" in any quoted-pair and the
CRLF in any FWS that appears within the comment are semantically
"invisible" and therefore not part of the comment either.
Runs of FWS, comment or CFWS that occur between lexical tokens in a
structured field header are semantically interpreted as a single
space character.
RFC 2822 is slightly stricter than RFC 822 in this regard. And while
it's not "full standard" like 822, it is a standards-track update to 822
and was sanctioned by the IESG as such, and was developed after years of
debate over good and bad behavior.
> and even then, the original thing was:
> Received: from ar39.lsanca2-4.16.241.28.lsanca2.elnk.dsl.genuity.net
> ([4.16.241.28] helo=watson1)
> and here helo=watson1 is inside parens, and with withespace (before and
> after the parens). or am I missing something?
Check the BNF again.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Is this Received header correctly formatted?
Posted by mouss <us...@free.fr>.
Eric A. Hall wrote:
>>
>> Huh? The helo= stuff is inside the parenthesis. Perhaps I am missing
>> something but your point 3 seems to conflicewith your point 2.
>
>
> comments are only allowed where whitespace occurs
>
can you give you me the line num in the rfc?
and even then, the original thing was:
Received: from ar39.lsanca2-4.16.241.28.lsanca2.elnk.dsl.genuity.net
([4.16.241.28] helo=watson1)
and here helo=watson1 is inside parens, and with withespace (before and
after the parens). or am I missing something?
regards,
mouss
Re: Is this Received header correctly formatted?
Posted by "Eric A. Hall" <eh...@ehsco.com>.
Christopher Weimann wrote:
> On 03/16/2005-04:49AM, Eric A. Hall wrote:
>
>>Loren Wilton wrote:
>>
>>>Received: from ar39.lsanca2-4.16.241.28.lsanca2.elnk.dsl.genuity.net
>>>([4.16.241.28] helo=watson1)
>>>by pop-a065d23.pas.sa.earthlink.net with smtp (Exim 3.33 #1)
>>>id 1DBKRe-0000Kp-00; Tue, 15 Mar 2005 14:23:22 -0800
>>>
>
> [snip]
>
>> 2) header data in parenthesis is comment data. comments are supposed
>> to be ~allowed anywhere that whitespace is allowed (this rule is
>> actually documented in RFC2822, which governs header fields). with
>> that in mind, yes, it's fine there.
>>
>> 3) the "helo=" stuff isn't conformant
>>
>
> Huh? The helo= stuff is inside the parenthesis. Perhaps I am missing
> something but your point 3 seems to conflicewith your point 2.
comments are only allowed where whitespace occurs
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Is this Received header correctly formatted?
Posted by "Eric A. Hall" <eh...@ehsco.com>.
Loren Wilton wrote:
> Received: from ar39.lsanca2-4.16.241.28.lsanca2.elnk.dsl.genuity.net
> ([4.16.241.28] helo=watson1)
> by pop-a065d23.pas.sa.earthlink.net with smtp (Exim 3.33 #1)
> id 1DBKRe-0000Kp-00; Tue, 15 Mar 2005 14:23:22 -0800
>
> 1) Is "stmp" in lower case valid, or should it have been STMP?
> 2) Is it valid to have the (Exim etc) stuff between 'stmp' and 'id'?
> 3) Anything else that may be off the mark?
The robustness principle says that you should be strict in what you send
and liberal in what you accept. From that perspective, it's not a
strictly conformant header, but its not broken enough for somebody to
refuse to parse it.
In answer to your questions:
1) the spec calls for uppercase
2) header data in parenthesis is comment data. comments are supposed
to be ~allowed anywhere that whitespace is allowed (this rule is
actually documented in RFC2822, which governs header fields). with
that in mind, yes, it's fine there.
3) the "helo=" stuff isn't conformant
Here's the BNF notation for the Received header as provided in RFC2821:
| Time-stamp-line = "Received:" FWS Stamp <CRLF>
|
| Stamp = From-domain By-domain Opt-info ";" FWS date-time
|
| ; where "date-time" is as defined in [32]
| ; but the "obs-" forms, especially two-digit
| ; years, are prohibited in SMTP and MUST NOT be used.
|
| From-domain = "FROM" FWS Extended-Domain CFWS
|
| By-domain = "BY" FWS Extended-Domain CFWS
|
| Extended-Domain = Domain /
| ( Domain FWS "(" TCP-info ")" ) /
| ( Address-literal FWS "(" TCP-info ")" )
|
| TCP-info = Address-literal / ( Domain FWS Address-literal )
| ; Information derived by server from TCP connection
| ; not client EHLO.
|
| Opt-info = [Via] [With] [ID] [For]
|
| Via = "VIA" FWS Link CFWS
|
| With = "WITH" FWS Protocol CFWS
|
| ID = "ID" FWS String / msg-id CFWS
|
| For = "FOR" FWS 1*( Path / Mailbox ) CFWS
|
| Link = "TCP" / Addtl-Link
| Addtl-Link = Atom
| ; Additional standard names for links are registered with the
| ; Internet Assigned Numbers Authority (IANA). "Via" is
| ; primarily of value with non-Internet transports. SMTP
| ; servers SHOULD NOT use unregistered names.
| Protocol = "ESMTP" / "SMTP" / Attdl-Protocol
| Attdl-Protocol = Atom
| ; Additional standard names for protocols are registered with the
| ; Internet Assigned Numbers Authority (IANA). SMTP servers
| ; SHOULD NOT use unregistered names.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/