Re: "Header Reordering", yet again

----- Original Message -----
From: "David MacQuigg" <david_macquigg(_at_)yahoo(_dot_)com>
To: <ietf-smtp(_at_)imc(_dot_)org>
Sent: Tuesday, May 31, 2005 3:16 PM
Subject: Re: "Header Reordering", yet again


> I would go even further and say re-ordering of headers by forwarders is
> very rare, but at this point I'm just guessing, so I'll keep  looking for
> any facts to the contrary.
No need to guess.  Its common sense.

First, if it was happening, obviously it isn't something that cause
problems.  Something that tends to cause a noticeable problem will typically
be a) public knowledge, and b) the vendor made aware.   When it comes to
non-isolated problems (a problem related to networking with others), the
problem is usually addressed pronto.  No company NDA will prevent the
exposure of public knowledge for a problem that is noticeable across points.

Point: Mail Distribution Software are the first to find out of problems when
it causes disruption or in the case of something new like a security
concept - a possible reordering issue.

Second,  Where is this Receive-SPF: analysis suppose to take place?

Think about it.   Here is a basic summary framework outline of our decades
old system that has evolved over time:

(01)  network
(02)  --> transport
(03)  --> (DATA) "passive" processor (MFA - mail filter agent)
(04)  -->  gateway (post smtp)
(05)  -->  host system storage
(06)       --o passthru (remote hosting)
(07)           --> push or pull transport
(08)           --> network
(09)       --o local (user hosting)
(10)           --o user online access (text, gui, web)
(11)           --o user offline access
(12)               --o interactive (i.e, pop3, imap)
(13)               --o automated (mail doors)

The possible Receive-SPF analysis points would or could be at:

Point 3 - mail filtering "passive" processor

Point 4 - Gateway?? Local or Domain

So far no damage due to header re-ordering issues.  It can't be presumed to
be incorrect because that means the software is broken.

Point 6?    Out of the question. Typically not something that would be
                part of the passthru/routing process.  But I open to discuss
                this in principle in regards to the chain of trust ideas.

Point 10?  This would be in interesting point, but usually
                the mail is already classified for the user at
                this point. No further server-side checking is done.

Point 11   Offline POP3/IMAP users?   This is what I was
               discussing with Paul  about.

Point 13:   Out of the question.

Overall, in regards to Received-SPF, I would only consider it be useful at
point 3 or point 11 and possibly point 4 if the MFA (mail filter agent) is a
post smtp concept.

Today, our 3rd party vendors use things like SpamAssasin at point 3 MFA
which is the done at the DATA state thus allowing for a dynamic rejection.
I can't tell you if SA is supporting the Receive-SPF: the SMTP processor
adds.

Point: By the time the SPF analyzer needs the header, there is no idea of a
possible reordering of the header.  It will be guarantee to be intact.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com