On Thu, Dec 06, 2001 at 05:43:15PM -0500, [EMAIL PROTECTED] wrote:
> --On Thursday, December 06, 2001 5:35 PM -0500 Peter W <[EMAIL PROTECTED]>
> wrote:
> > I like the basic idea a lot, but that doesn't look very backwards
> > compatible, though. Why not something like
> > RCPT TO: [EMAIL PROTECTED]
> > 250 [EMAIL PROTECTED] Recipient ok
> > OVRD "MAIL FROM: [EMAIL PROTECTED]"
> 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.
>
> [EMAIL PROTECTED]
>
> 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
[EMAIL PROTECTED]
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
_______________________________________________
Mailman-Developers mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-developers
