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 <doug.mtv...@gmail.com> wrote: > > On Jul 1, 2014, at 9:00 AM, Dave Crocker <dcroc...@gmail.com> 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 > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
