First of all, thanks for your quick help.
> /etc/postfix/main.cf:
> smtpd_sender_login_maps =
> unionmap:{hash:/etc/postfix/sender_logins.cf,
> pcre:/etc/postfix/sender_logins.pcre}
> [...]
Thanks for the trick. I did not realise that I could achieve that with a
regular expression.
>> I wonder whether Postfix is making this basic antispoofing feature
>> too hard for basic/economic mail hosters to implement. I am thinking
>> of some new, easy configuration option which rejects, or automatically
>> replaces, the "From:" mail header without resorting to external
>> filtering tools or to a full scripting language.
> And it mentions with https://github.com/magcks/milterfrom.
> [...]
> Postfix is not making it too hard. There is no deliberate effort
> to sabotage users. Postfix just does not have support built-in to
> make this particular thing "easy".
> [...]
The trouble is, the milter the documentation refers to only checks and
eventually fails, which could actually trigger the feared extra support calls
from non-expert users. I myself wouldn't worry too much about failing hard and
fast if the e-mail address does not exactly match, but matching the person's
name could be trickier (Mr. vs Mr, R. vs Robert, etc). Besides, compiling and
installing a milter is another hurdle. And option reject_sender_login_mismatch
only fails hard and fast too.
Automatically replacing (instead of failing) in both envelope and "From:"
header is probably achievable with a more advanced milter, but that requires
more skill and time than the "normal" sysadmin has.
I heard that Microsoft Exchange / Outlook 365 can easily enforce the right name
and e-mail address when sending with a policy setting. I think this is almost
always the right thing to do, in order to prevent impersonation within the same
company / domain, as e-mail impersonation can cause serious financial and
reputational trouble.
I understand that Postfix is open source software, probably subject to the
usual development limitations, but I nevertheless ask you to consider making
this feature easy. This kind of impersonation protection is a basic, intuitive
security feature, which should probably be configured on most systems nowadays,
just like SPF/DMARC is a must now. Incidentally, SPF/DMARC provide protection
against the same impersonation risk, only at higher level.
I wouldn't normally request such a feature in this kind of project, but I am
worried because, after so many years (or even decades), there seems to be no
off-the-shelf milter do to that, no easy Debian package, and no easy guide
"this is how you configure Postfix against local impersonation". This issue is
mostly ignored. I would have thought that most biggish web/mail hosters would
actually invest the effort to plug this hole, but apparently they do not, at
least around here. Basic mail hosting is probably so cheap now that most
providers try to upsell to a Microsoft or similar subscription instead, and it
is generally accepted that impersonation within an organisation is kind of
unavoidable otherwise. The most disturbing aspect is that this fact is never
documented upfront.
At the very least, I would mention in the Postfix documentation that
reject_sender_login_mismatch and the like are highly encouraged / should be
configured in most real-life systems in order to prevent local impersonation.
The "prevent impersonation" wording is important. That would at least remove
the last excuse I have heard from SMTP "experts" around here.
If making this easier in Postfix is nevertheless not feasible now, maybe
somebody else could point me to some existing hoster config screenshot, or some
existing e-mail server solution (hopefully open source, and not from Microsoft
or Google), where such impersonation protection is easily configurable. That
way, I could not only warn about the risk around here, but also present some
real-life examples of hosters or software which do take care in the right way.
Best regards,
rdiez
_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
