On 17 February 2018 at 17:21, Al Iverson <aiver...@wombatmail.com> wrote: > [....] > I am saying that I think it's unwise to put what amounts to > subscriber-level PII or basically clear identifiers in the Return > Path/MFROM, if mail back to that address is interpreted as an > indication that an action should be taken (like logging a bounce and > potentially stopping future mail to that recipient). It's an open slot > where an external actor could insert something to cause actions beyond > the expected ones. That counts as a security concern in my book. > > Yes, it is personally reasonable that different people will have > different takes on the level of concern associated with that potential > risk.
A good practice is to protect your VERPs with a signature (BATV or something similar may work). This is valid for both clear and obfuscated VERP paths. The use of IDs instead of the real original email in the return-path may also be because of length limits. Max length of an email address is 254 chars. If you have to insert it "almost clear" in a return path and change the domain then there are chance your return-path address will be more than 254 chars. so if your original address is "a 242 ti...@example.com" how do you add VERP to it without some sort of obfuscation? So, once you HAVE TO use some sort of obfuscation for long address, why should you prefer using 2 different algorithms? The obfuscated solution works for both short and long addresses. Also maybe we could differentiate between VERPs where the MAIL FROM simply depends on the recipient email address and VERPs where the MAIL FROM identify a single sent email (so if the same sender send another email to the same recipient using the same server the mail from smtp will be different). The give you 2 different level of "protection" and 2 different levels of "issues": BATV puts you in the second group, help you with backscattering, but don't help with deliverability where some recipient cannot whitelist you because their whitelist work on the return-path address and it changes every time. Stefano _______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
