I am in favor of it, as written, as well. -- Terry
From: dmarc [mailto:[email protected]] On Behalf Of Mike Jones Sent: Tuesday, July 1, 2014 11:20 AM To: Douglas Otis; Dave Crocker Cc: Pete Resnick; [email protected]; Barry Leiba Subject: Re: [dmarc-ietf] Draft DMARC working group charter I believe the WG charter is adequate as written. The activities described in section one of the working group activities addresses third-party email and DMARC. That section says that the working group will document the effects of DMARC on such mail flows and "consider mechanisms for reducing or eliminating DMARC's effects on indirect mail flows". I am in favor the of the WG charter as written. Thanks, Mike On Tue, Jul 1, 2014 at 10:45 AM, Douglas Otis <[email protected]<mailto:[email protected]>> wrote: On Jul 1, 2014, at 9:00 AM, Dave Crocker <[email protected]<mailto:[email protected]>> wrote: On 6/20/2014 12:38 PM, Dave Crocker wrote: Here is some draft text to consider for a DMARC working group charter: G'day, I've looked over the small amount of mail posted about the draft charter and do not see any changes mandated. Apologies if I've missed something, and I assure you it wasn't intentional. So please do re-state the suggestion. Otherwise, I think the major question now is whether there is general consensus on submitting this draft charter text to the IESG? Dear Dave, I do not think the charter is adequate. It needs to address the topic related to authorizing third-party use. Otherwise, it is not possible to address the resulting disruption when reject is ever desired in conjunction with a mixed use domain. At this point, it seems wrong to expect this problem will somehow evaporate. Several have suggested things like DKIM-Delegate, CDKIM, and the like. Frankly, your DKIM-Delegate distributes less data than would using the TPA-Label. However, TPA-Label requires much smaller DNS resources assuming public key retraction is to remain an important control aspect. IMHO, reliance on expiry represents a poor option. Improvements in DMARC features (identifier alignment, reporting, policy preferences) will be considered, such as: - Enumeration of data elements required in "Failure" reports (specifically to address privacy issues) - Handling potential reporting abuse - Aggregate reporting to support additional reporting scenarios - Alternate reporting channels - Utility of arbitrary identifier alignment - Utility of a formalized policy exception mechanism +- Domain Federation or Authorization scheme. See DKIM-Delegate or TPA-Label drafts as examples. Our company is willing to work with any large ISP to demonstrate use of TPA-Label. http://tools.ietf.org/html/draft-otis-tpa-label Such a conclusion is easily supported since only the DMARC domain receives feedback necessary to acknowledge and mitigate abuse of the From header field. As such, ONLY the DMARC domain is able to indicate which other domains are permitted (authorized or federated). Phishing and spoofing is an extremely serious problem NOT addressed using anti-SPAM techniques. If there is some time available in any upcoming meeting, I would like to take a few minutes to review this matter and relate our company's experience. Regards, Douglas Otis _______________________________________________ dmarc mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
