On 17 February 2018 at 02:19, Michael Peddemors <mich...@linuxmagic.com> wrote: > [...] > And since the direction most MTA's go is to reduce any form of 'bounce' or > backscatter, the idea of using the VERP to detect 'bounces' is probably not > as important as it once was, unless the emails are forwarded or client side > bounces)
"Non as important as it once was" does not mean the same of "it is harmful". I can agree that VERP is less effective than 10 years ago, but still it is the best way to detect some non deliverable email address. Without VERP a small percentage of underliverable keep generating bounces that you can't associate to any address. The main reasons for VERP to be less important today are: 1) much more receivers try to fail "in protocol" (but there are still many that do not) 2) much more bounces include the headers for the bounced message (and if you have the headers and you can parse them then VERP is not needed anymore. Unfortunately there are still some server accepting everything and sending bounces without headers or malformed bounces. > I personally believe that verp_respo...@esp.com is 'not' what good ESP's > should be doing, they should clearly reflect whom they are sending for in > the MAIL FROM, whether that be distinctive domain representing whom the > emails are for, or even better the person that it is sending for. > > When a large operator sends millions of emails all with the same VERP > style/pattern, it does a disservice. > > Now, of course some (and not going to point out names here) ESP's actually > like the VERP method, because if they have ONE too big to block company they > represent, they can use that as an excuse to have companies whitelist their > @esp.com domain, allowing a higher delivery account for all the other less > clean lists and senders.. I don't think it is fair to think the reason ESPs use VERP is this one. Neither they use @esp.com for this reason. Most ESP put "per customer identifications" in the headers (most time it is List-ID, some have their own header.. but they don't try to hide the sending customer): you can block the mime from, or you can block via list-id.. so the "too big to block" doesn't see a very strong argument. Using a return-path in the domain of your customer can be easy when you have a multi-thousands-dollars contract for each customer. But when you have "free" users or "few dollars per year" customers, you can't afford manually helping people to configure their domains so that you can use that in the return-path and then deal with major issues when the domain is "misconfigured" during a send. AFAIK, VERP has been introduced to deal with mailing lists issues and not by some evil-ESP group. > I think that transparency is important, and allows for the recipient to make > more informed choices as to the emails they want and don't want. Have you ever tried to look at the List-ID header and other headers? Also, most ESP don't alter the "mime from", so you can work on that for your reputation/spam.. if an ESP customer changes the mime from at every send and their ESP let them doing that to avoid spam filters then I suggest to ban the ESP. In the end, like any other sender (ESP are not so special), you will monitor some "rates" and decide if the sender is doing his antispam/antiabuse duties or not. > Of course, this is ONLY my personal opinion.. The world is not perfect, > but the ESP's who are sending with clear transparency are going to enable > their legitimate email to have a lot higher success rates. I'm not sure this would really happen to be true. Real world antispam filters are not that perfect too ;-) BTW I don't think that "ESP" in your arguments are worse than "any sender": doesn't the transparency argument apply to non-ESP senders? Do you manage any bulk sending service? Even a mailing lists would apply. If you don't use VERP, don't you see that kind of unidentifiable bounces I described above? How do you deal with them? Do you force re-confirmation of each recipient every few months? (are your sending-customers happy with that?). Stefano _______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
