On 5/17/15 7:38 PM, Stephen J. Turnbull wrote: > Scott Kitterman writes: >> On May 17, 2015 2:48:58 PM AST, "Stephen J. Turnbull" >> <step...@xemacs.org> wrote: >>> Scott Kitterman writes: >>> >>>> Performing prosepective DMARC validation on receipt to >>>> determine if mail would be subject to p=reject processing on >>>> the distant end if reransmited. >>> >>> I assume you mean "... and prospectively reject"? (GNU Mailman >>> at least already provides options to munge From or wrap the >>> message, conditional on the result of such a test.) >>> >>> For completeness it should be listed, > >> Dave asked for a comprehensive list, > > An acknowledgment of that is the first thing I wrote after asking > the qualifying question, as you see. > >> as you saw wouldn't be acceptable in many cases. > > The argument supports a stronger conclusion than that IMHO. Had > there been a wiki page for this list I wouldn't have posted here, but > I'm new and don't know the procedures for starting a page, and others > had posted to the list -- I just wanted the argument, and the > stronger conclusion, on the record in case I'm not around when the > wiki page or BCP or whatever does get initialized.
Dear Stephen, Wiki is fine, but traditionally anything somewhat involved should be published in the form of an Internet Draft. Reasonable tools are available. https://tools.ietf.org/html/draft-otis-dmarc-escape-02#section-4 Describes fairly easy approaches that require increasing cooperation from larger providers. 1) Conditionally permit Sender header field alignment This could be defined as a "public" policy that indicates as result of use of public mailing lists and general email use, the domain needs to allow alignment with the Sender header field. By having handling defined in such a case, it would allow recipients a safer way to override otherwise disruptive policies causing message being munged or placed into spam folders. 2) Define a replacement Author header This would better ensure email interchange rather than placing author roles into various ad hoc locations. 3) Third-Party Authorization Perhaps the effect made by option 1 or 2 may pressure providers into offering information that ONLY they have on behalf of their recipients. Such information would allow more effective and safer handling to deal of third-party sources where legitimate messages are likely disrupted with the effect of preventing open discussions with known authors. The Selection of which message are to receive a message siglet to authorize a third party domain could be accomplished using various DKIM siglets, but will require greater handling overhead and will be far less responsive when abuse is subsequently detected. Once the issue of overhead and responding to abuse are carefully considered, the general approach outline in https://tools.ietf.org/html/draft-otis-tpa-label-07 might be reconsidered. TPA-Label could even become a hybrid of https://tools.ietf.org/html/draft-levine-dkim-conditional-01 where initial signatures are confirmed by the https://tools.ietf.org/html/rfc6376 by using forensics base on the bh= and z= tag with an additional tag that indicates predefined sets of headers that must remain unchanged as well as a list of domains that may reintroduce signed messages. When an intermediary is authorized, an expanded authentication results header might prove simpler than using forensics. Either way, a hybrid approach would need less specified within TPA-Label resource records and still be able to retract specific authorizations that have gone bad. The hybrid approach would also help facilitate which outbound messages should receive the message siglets and which domains are authorized to re-sign on behalf of the DMARC domain. Various encapsulation scheme seem fairly risky since they allow unseen content to reconstruct messages that otherwise fail validation and will generally make email more confusing. Both encapsulation and DKIM siglets will allow wide-open abuse (abuse beyond the control of the DMARC domain). Regards, Douglas Otis _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
