[Top] [All Lists]

Re: "Header Reordering", yet again

2005-05-28 13:05:20

At 02:05 PM 5/28/2005 -0400, Bruce Lilly wrote:
On Sat May 28 2005 13:19, David MacQuigg wrote:

> I don't know what could be more clear than:
> '''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.
> '''  RFC-2821, section 3.6.

I think you might mean RFC 2822.

Correct.  Sorry for the slip.

It's clear -- if and only if one understands BCP 14 (a.k.a. RFC 2119).
In particular, note that "SHOULD" is a recommendation, not a requirement.


> Agreed.  My expectations are:
> 2) Trusted forwarders will follow the RFC-2821 requirements.

Note above re. the difference between "recommendation" and "requirement".
Note also that compliance with RFC N only applies to implementations which
are in fact compliant with the provisions of RFC N.  It is one thing for a
vendor to claim compliance, it is another to achieve it with a particular
version and configuration, and it is yet another to guarantee it regardless
of configuration.  Note well that there is nothing in a message that
indicates a claim of compliance (there may however be evidence of a failure
to comply, though it is not always clear where the blame lies).  Finally,
note that there is no enforcement mechanism for provisions in RFCs, even
those which are "requirements"; compliance is purely voluntary.  In
particular, there is no guarantee that all SMTP receivers comply with all
provisions of RFCs 821, 2821, and 2822.  Some of those provisions are
mutually contradictory, and it is a known fact that the vast majority of
SMTP receivers in fact do not comply with some provisions of all of those

OK, you have convinced me that there are loopholes in RFC-2822, and the spec for an authentication header MUST close those loopholes. Any spec I write will say something like - A Trusted Forwarder MUST NOT alter either the incoming headers nor the body of a message.

That still leaves open the question of how difficult it will be to enlist Trusted Forwarders. Is this a situation like SPF screaming "forger" at anyone who follows a widespread use of the MAIL FROM identity, or like CSV saying - You damn well better fix your EHLO name, no excuse. I'm leaning to the latter, but I could be convinced otherwise, if someone gives me more than vague words about some big forwarder that diddles with incoming headers.

If this is the unresolved core of this debate, we may need to do a survey. These mailing list discussions have put my BS detector on max.

I also note that as there is no standard definition of "trusted forwarders",
there is a danger that there is an attempt at a circular definition, which
would be of no value.

I would establish three levels of compliance for servers wanting to be listed as Public Mail Servers:

1) Servers that will declare their ID, and provide a DNS record to authorize the use of that ID.

2) Servers that will capture the IP address and any ID declared by the previous sender, and prepend that information in a standard authentication header.

3) Servers that will perform an authentication check on the declared ID, using any widely-accepted method, and prepend the result of that check.

Servers which only originate, and do not forward mail from other domains, need only reach Level 1.


************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *

<Prev in Thread] Current Thread [Next in Thread>