In favor as written. Brandon
On Tue, Jul 1, 2014 at 11:38 AM, Terry Zink <[email protected]> wrote: > 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]> > wrote: > > > > On Jul 1, 2014, at 9:00 AM, Dave Crocker <[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] > https://www.ietf.org/mailman/listinfo/dmarc > > > > > > > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc > >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
