[Mailman-Developers] Re: way to minimize IO load with MTA supported VERP

[Peter W]

On Thu, Dec 06, 2001 at 05:43:15PM -0500, tneff@bigfoot.com wrote:
> --On Thursday, December 06, 2001 5:35 PM -0500 Peter W <peterw@usa.net> 
> wrote:
> > I like the basic idea a lot, but that doesn't look very backwards
> > compatible, though. Why not something like

> >  	RCPT TO: johnsmith@aol.com
> >  	250 johnsmith@aol.com... Recipient ok
> >       OVRD "MAIL FROM: johnsmith-aol.com-mylist-owner@mydomain.com"

> I guess I was a little afraid that MTA's would get lost matching up 
> separately-issued RCPT TO: and OVRD commands that were supposed to function 
> as logical pairs.

Yes, that makes sense. But couldn't that be clarified in the new RFC/draft?

> I think that the ESMTP syntax would not be gravely 
> injured by adding another whitespace-separated atom after the TO: and 
> address, but I might be wrong.

Well, existing MTAs don't like it. sendmail says:
  RCPT TO: <nobody> VERP: other-string-here
  555 5.5.4 VERP parameter unrecognized
and I'd rather ask smtpd coders to add something new than extend something 
as critical as RCPT.

> Another approach would be to add a VERP "mode" with a single command:
> 
> 	VERP ON

> would automatically ensure that the envelope sender for that message would 
> be transformed according to a well-known rule, e.g.
> 
> 	johnsmith-aol.com-mylist-owner@mydomain.com
> 
> I think this would do the least violence overall because if VERP isn't 
> supported, no big deal, and the dialog syntax doesn't change in any other 
> way.

A couple problems I see with that:

 1) MTAs would have to be 100% uniform in the way they constructed
    VERP return paths, or apps like mailman would not be able to use them

 2) this takes aways some flexibility from the sending MTA, which currently
    has the flexibility to deal with VERP in arbitrarily complex ways. For
    instance, a sending MTA might use a hash routine and shared secret to 
    construct a return path like
johnsmith-aol.com-1007679391-351810f710b71cd6c44181f04c30dabd-mylist-owner@mydomain.com
    so that any returned messages can be cryptographically verified before
    being passed to mailman (I could be off-base here, but I'm 
    guessing/fearing that a miscreant could spoof some VERP bounces to a 
    mailman server and make mailman remove someone improperly)

-Peter

-- 
I am what I am 'cause I ain't what I used to be. - S Bruton & J Fleming