On Saturday, March 30, 2013 8:17 PM [GMT+1=CET],Mason Schmitt wrote: > > > I hope some solution to this problem with mailing lists is > > > found. > > > > On further consideration, there are some straightforward fixes > > that > > puts the work where it belongs and avoids causing damage to third > > parties; > > > > a) Implement p=reject by discarding mail rather than SMTP > > rejects. That's what we did in ADSP. You still run the risk of > > losing mail your users want, > > but that's between you and them, and it's inherent in any scheme > > like this. > > > > I think this is a good idea, but it does open the door for even more > ambiguity in how receivers implement DMARC. Perhaps it would make > sense > for a subsequent revision of the DMARC spec to include a policy of > 'drop' in addition to the existing 'reject' policy.
I like the idea. And what about including into the DMARC specification a "SoftFail" result, in which it would be required that both SPF and DKIM tests give a 'pass' result AND are aligned between themselves but not aligned with the RFC5322.From header? This will buy time for mailing list software to catch up with DMARC requirements and become, given enough time and as familiarity with DMARC becomes more widespread, full DMARC compatible. Will that DMARC "SoftFail" suggestion open a crack in the specification for phising email to get through somehow? Regards, J. Gomez _______________________________________________ dmarc-discuss mailing list [email protected] http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
