On Jul 16, 2013, at 8:46 PM, Roland Turner <[email protected]> wrote:
> On 07/17/2013 12:15 AM, Douglas Otis wrote: > >> From a specification standpoint, it seems odd to invalidate email from >> otherwise uninvolved domains that are technically RFC compliant. Wouldn't >> such specifications make the DMARC specification RFC ignorant? RFC5322 is a >> draft standard and RFC6854 is standards track. Requiring rejection of >> otherwise valid messages is hostile to those following standards. > > This viewpoint is incorrect and reflects an error in understanding that > senders frequently make. > > An SMTP server (or the host that it runs on) is the property of a receiver. > When a sender offers a message for delivery, the sender is asking the > receiver to extend a delivery privilege, a privilege that the receiver is > free to decline for any reason or for no reason. Dear Roland, Respect the rights of receivers over that of senders? Absolutely! There remains a need to defend receivers, and that is a clear reality. Asserting negative reputations against questionable DKIM domains carries significant risk because: 1) DKIM does not constrain message recipients. 2) DKIM does not constrain the initiating servers. 3) DKIM does not constrain the entire message. 4) DKIM can be replayed by design. While DKIM is ideal for BULK senders, DKIM completely ignores what is needed by third-parties to defend receivers. On top of that, SPF expects receivers to make as many as 111 DNS transactions to resolve Return Path authorizations which may include un-cacheable macro expansions? SPF macros are a rarely used option, when combined with DMARC, becomes an obligatory role for receivers on behalf of senders. To be more compliant, DMARC now wishes to couple Return Path authorization with any number of DKIM signatures where alignment with either DKIM or the Return Path must be determined for each of the FROM email domain(s)? Unlike Server Authentication where XMPP offers a good and workable example, DKIM, by its design, potentially permits abuse of receivers. DMARC recommends acceptance using EITHER SPF or DKIM after checking policy at domain(s) above the public suffix. DMARC does not deal with the issue created by RFC6854 which can be easily accommodated using the XMPP scheme of server authentication. Add a scheme similar to that of ATPS, and this would represent a defendable lightweight system able to defend receivers that DMARC/DKIM/SPF is unable to accomplish. There remains a need to defend receivers this remains a clear reality. Regards, Douglas Otis _______________________________________________ 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)
