Christoph Garst:
> > SRS is really a transformation that is tied to the SMTP protocol.
> I agree, SMTP would be a better place to transform the sender.
>
> > This could be addressed by making smtp_generic_maps more general,
> > such that there are separate variants for envelope sender, envelope
> > recipient, and likewise the message header addresses (perhaps with
> > names like smtp_sender_envelope_generic_maps, etc.)
>
> Extending smtp_generic_maps is nice, but won't help in this situation.
> A lookup table isn't sufficient to do the rewriting, we need a function
> like postfix_srs_forward (in analogy to verp_sender).
Postfix lookup tables are not limited to static files. One
implementation of SRS for Sendmail uses socketmaps, and I just added
Sendmail-style socketmap support to Postfix.
If the smtp_generic_maps feature were to be broken up into
smtp_{envelope,header}_{sender,recipient}_generic_maps then SRS
could plug into smtp_envelope_sender_generic_maps.
> I don't quite understand the DSN problem. If the envelope recipient is
> a srs address, the message is most likely a bounce. Are there any cases
> where someone is interested in DSNs of bounces?
Per your patch, the queue manager gives an SRS-ified envelope sender
to Postfix delivery agents. When a delivery agent can't deliver
mail, or when the sender has requested a DSN for other reasons,
then Postfix will send a DSN with the SRS-ified sender address in
the To: header. I suppose that is a feature of SRS, because a
bounce from a remote system would also look that way.
I was concerned that Postfix would not know how to deliver the
bounce, but it turns out that your patch will attempt to strip SRS
from all recipients as mail is queued, not as mail arrives via SMTP.
Wietse
