On Wed, 2012-06-20 at 03:30 +0900, Stephen J. Turnbull wrote: > Lindsay Haisley writes: > > > EVERP = Encrypted VERP > > Ever heard of "Occam's Razor"?
Yes, I'm quite familiar with it :) > Most folks who run Mailman lists can't > expand "VERP", and wouldn't understand the expansion when told. It's > not obvious to me that practioners would get it right, either. Let's > not proliferate unnecessary acronyms. I would not presume on the patience of the world (nor of the people on this list) by seriously proposing a YASA (Yet Another Stupid Acronym). My use of EVERP was for reference purposes on this list only. All other uses are explicitly and strictly prohibited. > N.B. That expansion doesn't say what kind of values the "variable" > takes, although the usual implementation assumes a friendly Internet > and uses addressee mailboxes. Wikipedia says, "However, some VERP > implementations use message number or random key as part of VERP", > which is close enough to "encrypted VERP" for me, YMMV. It's just an > implementation detail that really only concerns implementers.... Exactly. VERP refers to the concept of including a delivery address within the envelope sender address, which takes advantage of the RFC-prescribed practice of returning undeliverable email to the envelope sender address. > I'm not sure of this, but it seems to me that encrypted VERP should > work fine with greylisted recipients (if you can ever call the results > of greylisting "fine" :-P) as long as you don't change the encryption > key very often. Well the implementation I've developed for use with Resent-Message-ID incorporates a random factor into the AES encryption so that every encryption of the same address is different, although all decrypt properly using the key with which they were encrypted. This could, of course, be changed. > In Mailman 3, I would suppose it won't be hard to store the encrypted > form along with the rest of the user's profile. Yes, which would make the VERP consistent, if greylisting cares. It might also be possible to generate and store encryption keys per list rather than per site, as my experimental implementation (mm 2.1.15) does. -- Lindsay Haisley | "The only unchanging certainty FMP Computer Services | is the certainty of change" 512-259-1190 | http://www.fmp.com | - Ancient wisdom, all cultures ------------------------------------------------------ Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
