Hi,
So I took upon myself to work on the masquerading feature everyone keeps
requesting every now and then.
In my sandbox I have working initial support for masquerading, and it is
the first of a serie of three planned incremental improvements.
Recently, we introduced "senders map" support which allows postmaster to
limit the addresses a user is allowed to submit at the SMTP level:
table mylist { gilles = [email protected] }
listen on all [...] auth senders <mylist>
This for example, means that user gilles HAS to use the [email protected]
as its email address in the MAIL FROM part of the SMTP transaction.
However the mail content is not inspected and gilles is still allowed to
do the following:
MAIL FROM:<[email protected]>
250 2.0.0: Ok
RCPT TO:<[email protected]>
250 2.1.5 Destination address valid: Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
From: [email protected]
[...]
.
which is valid as far as SMTP is concerned, is correct as far as senders
map is concerned, but will still result in a From the user can forge.
The first commit I will do, will introduce the following syntax:
table mylist { gilles = [email protected] }
listen on all [...] auth senders <mylist> masquerade
Where "masquerade" is an option to the senders feature.
When set, email addresses in the From header will be rewritten to match
the email address that the user has used in the SMTP session. With this
a user can no longer have a From that differs between the SMTP session
and the DATA content.
Furthermore, since this senders map feature allows a user to map to a
different set of addresses:
table mylist { gilles = "[email protected],[email protected]"
And since the masquerading feature uses the email address that was
validated by the senders map feature, it means that masquerading will
automagically pickup the proper sender if many are specified.
Eric has okayed, I'm waiting for an ok from Sunil and I can commit this
so it is part of the next snapshot.
What's next ?
1- the masquerading feature will be extended so that what I described is
the default behaviour but so that different mappings may be provided:
table mylist { gilles = [email protected] }
table masq { [email protected] = [email protected] }
listen on all [...] auth senders <mylist> masquerade <masq>
In this case, gilles is allowed to submit as [email protected], but
masquerading will rewrite that address to [email protected] in the DATA.
2- code cleanup, there's a large portion of identical code between the
domain append feature and the masquerade feature. Since this is so
tricky, I decided to duplicate the code until I'm done with the whole
masquerade feature and I can start factorizing.
--
Gilles Chehade
https://www.poolp.org @poolpOrg
--
You received this mail because you are subscribed to [email protected]
To unsubscribe, send a mail to: [email protected]
