Jim Ramsay <[EMAIL PROTECTED]> writes:

> It may be important for TMDA to know about what the final verdict on
> this is, as it may change the way TMDA would operate if DELIVERY is
> set to forward to an email address.

That's true, as currently TMDA does preserve the original envelope
sender when forwarding.  This follows the behavior of qmail and
Postfix, but not Sendmail, which rewrites using the forwarding
address.

> We may actually have to look at implementing SRS for those wanting
> to forward emails to SPF/SRS-enabled servers.  I don't know if there
> are any yet, but it may be important in the not-too-distant future
> as the SRS spec solidifies and people start using it.

I don't have any problem with this if SPF really takes hold.  Clearly
the SRS spec needs lots more work though as it is much too ambiguous
currently.

Of course, we could just follow the procmail example in
http://spf.pobox.com/faq.html and forward using a bitbucket or null
envelope sender address.

Uh yeah, right.  Frankly, I'm shocked they even mention this.  If
the forward bounces, the original sender will never know it.

> Then again, this may be better done in the MTA.

How so?  Will the MTA provide a hook such as a /usr/sbin/sendmail
compatible program that does the SRS rewriting in a way where the MTA
can handle a return trip by the message in the case of a bounce?  The
benefit here is that every external forwarder (TMDA, maildrop,
procmail, etc) wouldn't have to implement SRS.
_________________________________________________
tmda-workers mailing list ([EMAIL PROTECTED])
http://tmda.net/lists/listinfo/tmda-workers

Reply via email to