[EMAIL PROTECTED] wrote:
.
.
.
In the dark ages of SMTP, few headers were added by receiving
servers, and only one was important - the Received: header. So
Received: headers are piled in dirty-laundry fashion, with the newest
on top, but the rest of the headers are in basically random order.
RFC2822 is very clear about messages headers and ordering. To quote part
of section 3.6
It is important to note that the header fields are not guaranteed to
be in a particular order. They may appear in any order, and they
have been known to be reordered occasionally when transported over
the Internet. However, for the purposes of this standard, header
fields SHOULD NOT be reordered when a message is transported or
transformed. More importantly, the trace header fields and resent
header fields MUST NOT be reordered, and SHOULD be kept in blocks
prepended to the message. See sections 3.6.6 and 3.6.7 for more
information.
As such I would consider any application that requires headers to be in
a particular order.
In this day of AV milters and SPF checks and DomainKeys and spam
checks and whatnot, receiving servers are adding more and more
headers -- and these headers are becoming more and more important.
These headers frequently make the difference between Inbox and Junk
(a fate worse than REJECT!)
The question of spoofed headers then becomes critical. Adding
headers at the top rather than the bottom makes it easier to detect
whether a header has been spoofed.
Consider a sample email with clamav-milter -I:
X-Virus-Status: Clean Received: from some-box by
my-clamav-milter-server Subject: ...
Because the X-Virus-Status: line is ABOVE the Received-line, I know
it was added by the clamav-milter immediately, just by looking at the
order of the headers.
Whilst that might be the case when the MTA is performing the final
delivery step, in general this option does not appear to be very useful.
Both RFC2822 and RFC2821 discuss the trace header fields (Received:
etc.) and the specifics of a.) keeping these headers together in blocks,
and b.) prepending these trace fields to the message body. By inserting
these X-* headers in specific positions you are assuming that no
downstream MTA is ever going to reorder those headers. That may not be
the case, and if any downstream MTA does decide to perform some header
reordering (for example to keep the Received: headers in a block), be
that right or wrong, your header may still appear at the top, or it may
have been repositioned below the Received headers. In any multi-tier
mail server environment this would most definitely be a valid scenario,
and a potential problem.
On the other hand, without clamav-milter -I:
Received: from some-box by my-clamav-milter-server Subject: ...
X-Virus-Status: Clean
... there are at least possibilities to consider: 1) Most likely is
that clamav-milter is working, and X-Virus-Status: Clean was added by
my clamav-milter. 2) But there's a nagging doubt in the corner of my
mind that my clamav-milter is broken and the X-Virus-Status: Clean
was already there.
Relying on the existence of particular headers to determine if some
action (eg. virus scanning) has been taken or not, does not seem to be a
good idea at all, given how easy it is for messages to be forged. If
these message headers are so important to you, then it would seem to be
appropriate to first remove any such headers upon message acceptance by
the MTA, PRIOR TO clamav-milter processing beginning. Whether this can
be done with with clamav-milter or your particular MTA configuration, I
do not know, since I confess I am not a user of clamav-milter, nor Sendmail.
So in general adding headers at the top is a Good Idea.
But it's not just a Good Idea - it's also what service providers are
doing! For example, Yahoo and Gmail.
I disagree that it is a good idea. I also note that just because a
couple of ISP's do it certainly doesn't make it right, nor should it
make it an accepted practice.
Cheers
Andrew
_______________________________________________
http://lurker.clamav.net/list/clamav-devel.html
