> -----Original Message----- > From: Vlatko Salaj [mailto:[email protected]] > Sent: Monday, June 09, 2014 10:45 AM > To: MH Michael Hammer (5304); Talamo, Victor > Cc: [email protected] > Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out > > On Monday, June 9, 2014 3:28 PM, MH Michael Hammer (5304) > <[email protected]> wrote: > > > > > FP rates ranging from .17% to .3% > > so, in 1 000 000 000 of notifications, 1 700 000 to 3 000 000 is lost. > and u don't consider that a problem? > > let imagine u have 333 333 customers. and u get a security breach. > and u decide to send instant security notice to customers by email asap. > and about 1000 customers possibly doesn't receive any such notice, and > about 560 of them doesn't get one for sure. and one of those 560 happens to > be a millionaire with a forwarding email account which serves his iphone. > > well, if i were a bank, i would consider that a bad situation. >
Financial institutions can speak for themselves. I will point out that this is about tradeoffs rather than absolutes. The majority of false positives I see are because of forwarding on the recipient side. This is something the recipient can choose to address or not.It is beyond the control of the originator of the message. For the financial institution the tradeoff is how many of their customers are getting phished or abused because of fake notifications (or similar) claiming to be from their domain which some significantly larger number (than the FPs caused by DMARC) of their customers are impacted by (as in theft of funds from their account). That is a worse situation - for both the customer and the financial institution. This is also why the financial institution asks for cellphone (SMS communication and/or voice), home phone and physical mailing address. If it is important enough then sending an email over the transom is not the way to ensure that the recipient gets the message. This has been an issue even absent SPF/DKIM/DMARC. > > >> exactly the reason behind DMARC being an independent document on > IETF. > > I think all who were "in the room" would agree that the failure to do > > so was not a function of false positive rates. > > actually, my point was that DMARC excludes too much of legitimate email, > not just false-positives. > > but i guess it depends how u define too much. > Each domain, each user, each mailbox provider and each 3rd party service provider (for example MLs) will have a different definition based on their perspective, needs and desires. > > not that it matters anyway. i'm somewhat sure any IETF DMARC work would > include 3rd party support, so imo, we have passed the point of no return, > and we r working to bring false positives down. > I expect we will see solutions that will address various aspects of FPs. There will always be a certain amount of FPs that any reasonable person would expect. I have not seen much discussion of transient FPs where the validator is unable to look up the SPF or DKIM record. It does happen. _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
