Rewriting envelope sender for aliases
Hector Martin
I have Postfix configured with delivery through virtual. Some users get
IMAP mailboxes and some users have their mail redirected elsewhere. I
have virtual_alias_maps set to a file like this:
f...@example.com foo...@gmail.com
...
I find that sometimes my mail is dropped by filters along the way
because the envelope sender is not modified. For example, if
b...@gmail.com sends mail to f...@example.com, mail.example.com ends up
sending out mail from b...@gmail.com (to foo...@gmail.com), which may not
be seen as very legitimate and goes against SPF for some domains.
What I want to do is rewrite the envelope sender such that it appears to
come from the left hand side of the alias map file, so a mail from
b...@gmail.com to f...@example.com would turn into a mail from
f...@example.com to foo...@gmail.com. Is there a way of doing this in
Postfix?
--
Hector Martin (hec...@marcansoft.com)
Public Key: http://www.marcansoft.com/marcan.asc
Victor Duchovni
> What I want to do is rewrite the envelope sender such that it appears to
> come from the left hand side of the alias map file, so a mail from
> b...@gmail.com to f...@example.com would turn into a mail from
> f...@example.com to foo...@gmail.com. Is there a way of doing this in
> Postfix?
Perhaps with an SRS milter, or similar content filter, assuming these
take extreme caution to avoid loops (never rewrite "<>" to a non empty
return path) and provide appropriate means for bounces to come back to
the original sender in most cases.
Nothing built-in, because supporting the return path requires non-trivial
state.
To support this in Postfix itself, one needs an address class for domains
handled in this way, and a special delivery agent that processes mail
for such domains.
The delivery agent would:
- Securely handle return-path transformations to allow back-propagation
of bounces.
- Carefully replace the sender address before forwarding messages.
Deal with DSN notification attributes, ...
The SMTP server would perhaps need to be able to validate authenticated
bounces to return paths generated by the redirect delivery agent.
Alternatively, since bounces don't bounce, one could consider receiving
mail to any address in such a domain, provided the sender is "<>".
You would still be able to alias selective users in normal domains, but
would do indirectly. Hypothetically:
main.cf:
indexed = ${default_database_type}/${config_directory}/
redirect_transport = redirect
redirect_domains = redirect.example.com
redirect_maps = ${indexed}redirect_maps
virtual_alias_maps:
us...@inside.example.com uni...@redirect.example.com
redirect_maps:
uni...@redirect.example.com us...@outside.example.net
You would still need to spam filter very well before forwarding
significant volumes of email, otherwise the reputation of your forwarding
systems will be poor, and they experience delivery issues despite
(double negative) lack of SPF non-compliance.
No such delivery agent has been written, or address class implemented,
these are just random thoughts on what this would look like if supported
directly, rather than in content_filter or milter.
--
Viktor.
Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.
To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:majo...@postfix.org?body=unsubscribe%20postfix-users>
If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.
Hector Martin
> On Thu, Jan 14, 2010 at 01:11:17AM +0100, Hector Martin wrote:
> Perhaps with an SRS milter, or similar content filter, assuming these
> take extreme caution to avoid loops (never rewrite "<>" to a non empty
> return path) and provide appropriate means for bounces to come back to
> the original sender in most cases.
>
> Nothing built-in, because supporting the return path requires non-trivial
> state.
Well, I clearly underestimated the effort required to make this work
sanely. How about something simpler, like just rewriting the envelope
sender to postmaster (i.e. me)? This is a small system, and bounces from
the final destination servers should be rare. This way I'd get any such
bounces and would be able to (manually) deal with them appropriately.
Victor Duchovni
> Victor Duchovni wrote:
> > On Thu, Jan 14, 2010 at 01:11:17AM +0100, Hector Martin wrote:
> > Perhaps with an SRS milter, or similar content filter, assuming these
> > take extreme caution to avoid loops (never rewrite "<>" to a non empty
> > return path) and provide appropriate means for bounces to come back to
> > the original sender in most cases.
> >
> > Nothing built-in, because supporting the return path requires non-trivial
> > state.
> > [...
>
> Well, I clearly underestimated the effort required to make this work
> sanely. How about something simpler, like just rewriting the envelope
> sender to postmaster (i.e. me)? This is a small system, and bounces from
> the final destination servers should be rare. This way I'd get any such
> bounces and would be able to (manually) deal with them appropriately.
This still requires a content filter. Contortions with multi-stage
forwarding, with custom rewriting in downstream stages are possible,
but are not a good idea.