On Thursday, March 26, 2015 3:08 AM [GMT+1=CET], Hector Santos wrote: > SPF had a strong REJECTION concept with RFC4408 and with the latest > spec RFC7202, it was relaxed with allowing for quarantining ideas > (mail separation). RFC7208 made RFC4408 more costly by adding more > complexity for an "ACCEPT/SEPARATE" mode of operation for failed SPF > messages as opposed to just REJECTING failed SPF messages. > > Part of the problem is that the idea of quarantine does presumed a > backend mail storage design that mail separation was even possible. > It is not an universal concept to have this multiple mail folders > idea, ability and/or MUA/UI infrastructure for end-users. So in that > vain, it does come with a high support and also high implementation > cost to include Mail Quarantine functionality into a specification. > REJECTION is a must lower design implementation cost.
+1. For Google/Hotmail/big-ESP, the support costs are already accounted for in their cost structure. For small or "boutique" Email Service Providers, support costs are very important and can grow very fast: an user has a problem with suspect or missing email?, we go on-site, we hand-hold them, we give face, we remote into their system and get to deal with the mess, we do whatever until the troubled user finds peace... If DMARC is going to increase support costs for small email operators, I may as well migrate all my clients to Google Apps or Office 365 and be done with costly email. That is why, in my view, DMARC's p=reject has to either be reliable to be relied on, or be suppressed from DMARC's formal specification if it is going to mainly be equal to p=do-whatever. Regards, J.Gomez _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
