Re: "Header Reordering", yet again

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
> RFCs.
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.
--
Dave

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