Ned, I like the tone of this response much better than your last. It's OK
to disagree, let's just avoid calling each other idiots.
At 09:13 AM 5/28/2005 -0700, Ned Freed wrote:
At 08:05 PM 5/27/2005 -0400, Bruce Lilly wrote:
>On Fri May 27 2005 18:49, David MacQuigg wrote:
>
> > We don't expect every sender to be
> > compliant, just the ones that want to be trusted as Public Mail
> > Servers. This may be a small number at first. Then others will
discover
> > the benefits of becoming compliant - bypass the spam filtering.
>
>Past experience with SPF indicates that spammers -- who have financial
>incentive -- will be early adopters, and legitimate mailers who don't
>conform to your preconceived notions will be harmed. The spammers
>will claim that because they comply with your scheme, they aren't
>really spammers at all. The scheme -- like SPF -- would be doubly
>harmful.
We seem to be losing context again. The question is whether we can specify
that Trusted Forwarders MUST NOT reorder trace headers, using the same
language as the words from RFC-2822 that you snipped.
The problem is the language is ambiguous at best as to whether it covers
relative ordering of two different fields. It is also unclear as to whether
new fields can be added to the set of trace fields willy-nilly.
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.
New header lines *have* been added with no apparent breakage. Almost every
email I see has lines like:
X-Persona: <yahoo>
X-Apparently-To: david_macquigg(_at_)xyahoo(_dot_)com via 68.142.198.149; Sat, 28 May
2005 09:33:48 -0700
Authentication-Results: mta292.mail.scd.yahoo.com
from=mrochek.com; domainkeys=neutral (no sig)
X-Originating-IP: [209.55.107.55]
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed
A new authentication header would be ignored by old systems, and for new
systems, we can require that it have a particular position, at the boundary
of an administrative domain.
But as I have said before, you are insisting on pursuing a specific
problematic solution despite the fact that there are other ways to
deal with this that don't open this particular door.
I haven't proposed a solution. This thread started with Bruce Lilly's
statement that we could not depend on header order. The last time we had
this discussion, the thread dissolved in noise before reaching a
conclusion. I'm attempting to keep this thread on track.
Valdis Kletnieks already
pointed out that SPF information could be piggybacked on existing Received:
fields. I have yet to see an agent that reorders Received: fields. I have
seen agents modify or drop Received: fields, but this behavior seems to be
fairly disjoint from the sorts of forwarders where we want order to be
preserved.
Well, this is encouraging. Maybe we can at least count on Public Mail
Servers acting as forwarders on the open Internet to not screw with
existing headers. Perhaps you could clarify your earlier example of "large
ISPs with millions of customers". Which ISPs are you talking about? Are
they acting as forwarders, or final destination receivers?
It is all a question of using the right mechanism and having realistic
expectations.
Agreed. My expectations are:
1) Spammers can't mess with headers prepended after the email is out of
their domain.
2) Trusted forwarders will follow the RFC-2821 requirements.
3) Authentication headers added by a Trusted Forwarder will not break
downstream MTA's.
4) Header reordering will occur only before the first Trusted Forwarder, or
after authentication at the final destination.
--
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 *
************************************************************ *