Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

currently, i find myself in the situation where once Postfix 2.11 has been configured to properly reject outbound forged emails addresses when sender login mismatches and also when sender address does not owns login address. The from/sender email address is usually able to be changed through email clients Identity edition feature.

So, to prevent sender email address forgering i mainly setup the following rules:

## Here we get email addres.
smtpd_sender_login_maps = proxy:mysql:/etc/postfix/mysql_sender_login_maps.cf

smtpd_sender_restrictions =

Through the previous settings i'm able to reject emails when sender email address does not match above requirements once Identity has been edited through Identity edition tool which comes with Roundcube, Mozilla Thunderbird, etc. Right here things are perfect.

Bellow is the output shown at mail.log

Note: foobar@foobar.com is the sender address i do not own and which must be correctly rejected while sender@login-domain.es is the real/good sender address used to authenticate. And the one which should always be used for sending reasons.  

<foobar@foobar.com>: Sender address rejected: not owned by user sender@login-domain; from=<foobar@foobar.com> to=<pau@example.es> proto=ESMTP helo=<host.example.es>

Here is the complete mail.log output: https://gist.github.com/sibok/0fe21a1415fe4e30ade3

Although previous scenario seems to work fine there's really an issue or uncontrolled use case which happens when Identity is edited through AfterLogic Webmail client. When sender address has been editted through AfterLogic, once the email is sent, the from address which seems to be used for sending purposes - looking at mail.log - is sender@login-domain.es but then looking at the log you also can see new foobar@foobar.com address appears at opendkim mail.log line and also in the headers once the email is sent. So somewhere foobar@foobar.com is used as from: address but it looks transparent at mail.log file.

Here's what can be seen:

opendkim[17106]: 72C664232B: no signing table match for 'foobar@foobar.com'

Here is the complete log output https://gist.github.com/sibok/2048b242c54a171b2a9e

Here there are email headers, once the email has been received at Google Apps. https://gist.github.com/sibok/c0d9e5391ae8b71d687f

You can see from: belongs to foobar@foobar.com while return-path belongs to the login/authentication address.

From: "test" <foobar@foobar.com>

Return-Path: <sender@login-domain.es>

The following Gist is the current Postfix configuration, without edits. https://gist.github.com/sibok/e66a5e3d84811c7afc98

Does anyone knows what's going on and how to solve that issue?

Thanks in advanced!

share|improve this question
Is the webmail on the same machine? smtpd restrictions only deal with networked connections, if it's coming through localhost, smtp deals with it. –  NickW Mar 31 at 13:29
Hi NickW!! Yes, currently i'm testing Roundcube, RainLoop and AfterLogic Webmail. All of them on the same machine and i only noticed this issue with AfterLogic Webmail. I'm going to check Postfix restrictions and master.cf, meanwhile here's my current config gist.github.com/sibok/5cf19d27c84a152e8335 Also, could you please be more precise on what i'm doing wrong? Right now restrictions are set in main.cf smtpd_*_restrictions and i'm not verwritting them through smtp master.cf specific settings –  user846226 Mar 31 at 13:34
You know what I'd do? I'd configure AfterLogic to send through the submission port, that way it will do a SASL login. –  NickW Mar 31 at 13:40
It is currently configured to connect to so it looks pretty strange to me. I see the work flow changes, as with Roundcube, RainLoop, Thunderbird or whatever when spoofing from/sender address i can see in the log fiel it is used everywhere so a Postfix rejection is thrown but with AfterLogic Webmail you can see in the logs posted above foobar.com only appears in the dkim check. Here's the headers of the email once received at Google Apps gist.github.com/sibok/a4aa6f96723628efa24e –  user846226 Mar 31 at 13:53
Yeah, you do seem to be doing everything correctly, I wonder if one of the permit_sasl_authenticated lines is short circuiting the checks.. in those stmpd_X_restrictions a permit means it won't check further. I see you can set Allow users to change email settings This option allows or forbids users to change their account settings ("Friendly Name" can be edited anyway). in AfterLogic, though that doesn't really fix the problem.. –  NickW Mar 31 at 14:14
show 5 more comments

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.