On Jun 5, 2009, at 6:36 AM, Charles Lindsey wrote: > On Thu, 04 Jun 2009 20:19:34 +0100, Douglas Otis <do...@mail- > abuse.org> > wrote: > >> On Jun 4, 2009, at 5:20 AM, Charles Lindsey wrote: >> >>> On Wed, 03 Jun 2009 17:13:02 +0100, Murray S. Kucherawy > >>>> You're not required to sign them, but it's not a bad idea. >>> >>> Then why are people on this list not trying to enocourage that >>> good practice? Indeed, why are they so vociferously trying to >>> DIScourage it? >> >> Before A-R headers can be trusted, A-R headers MUST be removed by >> incoming border MTAs. See section 1.6 of RFC 5451. > > No, that is NOT what section 1.6 of RFC 5451 says. It requires > removal of any pre-existing A-R header "claiming to be valid with in > its [the ADMD's] boundaries", which essentially means (AIUI) any A-R > header that might be mistaken for one that might/would/should have > been created within that same ADMD.
By selecting specific A-R headers to remove, header content might be processed post delivery, and then appear to match against some trusted domain. The safest solution would be to remove _all_ A-R pre-existing A-R headers from different environments or not since they may not have been treated as trace headers or are encoded in some fashion. It is hard enough to decide whether A-R headers that appear to be from the incoming domain can be trusted. To better ensure trustworthiness of A- R headers, it seems wise to remove _all_ preexisting A-R headers. Until A-R handling has demonstrated consistent safety, and not just safe most of the time, it seems imprudent to trust foreign A-R headers. YMMV. > BUT the cases we are considering are where, in the course of its > travels, a message has picked up two signatures, S_1 and S_2, but > where S_1 has (possibly) been invalidated by some change at an > intermediate site (typically a mailing list expander) en route, and > even where S_1 has been removed at some point. So there are at least > three ADMDs involved: > > | sending ADMD | Mail List ADMD | Receiving > ADMD | > | orig MUA orig MTA | | Recv MTA > Recv MUA | > | M ---> M+S_1 --+-> M+S_1+A_1 -> M*+A_1+S_2 --+-> M*+A_1+S_2+A_2 > --> | > > A_1 was added by a validator/assessor on the strength of S_1 > A_2 was added by a validator/assessor on the strength of S_2 > Observe that M was transmogrified into M* at some point, breaking S_1. > > If some "helpful" MTA, somewhere between the Mail List and Receiving > ADMDs, had also added an A_2, then THAT is the one that should be > removed by Recv MTA, before inserting its own (which it obviously > would not do if S_2 covered A_1, and A_1 was no longer there). > > What Recv MTA passes on to Recv MUA is entirely a matter to be > decided within the Receiving ADMD, but I hope it would be everything > that was available (even S_1 if it were still available). > > Note that Appendix B.6 of RFC 5451 contains an example exactly > equivalent to the one I have just given, including the retention of > A_1 (and even S_1). IMHO, appendix B.6 is overly optimistic for today's environment. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
