Smarthost blocks delivery of spam to collector mailbox

[ons]

Hello Marius, and thanks for a product which looks very interesting! I have installed Scrollout two days ago in front of an Exchange 2010 server, and although I have not yet trained the Bayesian classifier it is already performing well.

I have, however, found a problem with the use of smarthosts, which I think is related to this topic: http://sourceforge.net/p/scrollout/discussion/1102835/thread/6247ce4a/

In my case, when I enable a smarthost in Route::PrimaryDomain::Outbound, the delivery of spam to the collector mailbox generates this error:

Dec 21 00:13:33 mail postfix/smtp[53287]: 3k4j2G2fsxz5vC9: to=spam@mydomain.com, relay=10.0.0.3[10.0.0.3]:25, delay=1111, delays=1106/0.06/5/0, dsn=4.7.3, status=deferred (SASL authentication failed; server 10.0.0.3[10.0.0.3] said: 535 5.7.3 Authentication unsuccessful)

On Exchange, I get:

(translated from Italian) Inbound authentication failed with LogonDenied error for connector Default SERVERMAIL. Authentication mechanism: Ntlm. IP Address of client which attempted authentication on Microsoft Exchange: [10.0.0.50].

As soon as I remove the smarthost, spam is delivered successfully to my collector mailbox.

Is this an intended behaviour or something which needs to be fixed?

During the Christmas period I really need to use the smarthost, because there are some hosts which are refusing direct connections from Scrollout, as I've not yet setup a PTR pointing to my SMTP host.

So at the current time I'm using Scrollout without smarthost, but if I see that there is some mail stuck in queue (because direct delivery is blocked), I enable the smarthost for a minute, so that mail is delivered, and then I remove it again. Of course this can make sense during this holidays period, but not on the long run.

Thank you very much for your help, and for a great product!

[Anonymous]

UPDATE: I spent some hours studying Postfix (about which I knew nothing, tbh), and I thought I found a workaround which allowed me to keep using the smarthost, by changing sasl_passwd into:

postmaster@mydomain.com    EXCHANGEUSER:EXCHANGEPASSWORD 
@mydomain.com    SMARTHOSTUSER:SMARTHOSTPASSWORD

where EXCHANGEUSER is an Exchange user with global Send As privilege, so that it can send as postmaster@mydomain.com

The workaround works, in that spam reports sent from Scrollout (postmaster@mydomain.com -> spam@mydomain.com) are delivered, but there are some caveats.

1) if I understand Postfix correctly, any attempt to send mail from postmaster to inet addresses would try to authenticate with the remote host using EXCHANGEUSER:EXCHANGEPASSWORD, which is something I don't want (and it wouldn't work anyway). And even if mail was not sent directly but via the smarthost, the wrong credentials would be used.

2) I got a stuck mail from user1@mydomain.com to user2@mydomain.com... The problem here is that user1 is an external user who does not (and cannot) use Exchange directly (via Outlook Anywhere interface), it uses the server from the outside as a normal POP/SMTP server. Now that the SMTP "server" is Scrollout, the message from user1 to user2 is delivered by Scrollout to Exchange using SMARTHOSTUSER:SMARTPASSWORD (or so I think) but of course this fails. To be sure, I tried to remove the smarthost, and the message was delivered immediately.

3) I don't understand why messages from external senders are delivered to Exchange without authentication (when the smarthost is enabled), but I guess that this happens because they (and their domains) are not listed in sasl_passwd?

All in all, it looks like sasl_passwd is not "powerful" enough when smtp_sender_dependent_authentication=yes. It should be more flexible, allow to define triples (user, destination host, auth) rather that couples, and permit optional authentication and catchall destinations, something like this:

postmaster@mydomain.com, *           , NONE
@domain                , exchangeHost, NONE
@domain                , smartHost   , SMARTHOSTUSER:SMARTHOSTPASS
@domain                , *           , NONE

Or it could be that I've not studied enough, and there is a simple solution but I cannot see it :-)

Now I wonder whether defining an ad hoc transport which disables authentication could be of any use, but honestly my knowledge about Postfix isn't good enough to do a reliable test :-/

I'll let you know if I find out something interesting and usable, meanwhile thanks for your attention.

[Anonymous]

Still on it... Now I'm using the default configuration, with smarthost enabled, and a single change:

-o smtp_sasl_auth_enable=no

in master.cf, for the transport which delivers mail to Exchange, and everything appears to work...

postmaster@mydomain.com -> spam@mydomain.com works (tested via sendmail on Scrollout host, no authentication error)

user1@mydomain.com -> user2@mydomain.com works (as above, no authentication error)

user@mydomain.com -> me@gmail.com works (as above, and checked via headers that the smarthost has been used)

me@gmail.com -> me@mydomain.com works (tested by sending a message from gmail)

What do you think about this "solution"?

Thanks!

[Marius Gologan]

Hi,

SASL authentication can be complicated when Sender dependant and routes are involved.
Anyway, the initial error says:
"SASL authentication failed; server 10.0.0.3[10.0.0.3] said: 535 5.7.3 Authentication unsuccessful"

In short, 10.0.0.3 rejects SMTP delivery because:

1. SASL authentication is required; or
2. SASL authentication is wrong (wrong username and password); or
3. Username is different than the Sender; or
   All 3 together.

My advice is to remove authentication from 10.0.0.3 for Scrollout (hostname or IP address).
If points 1 and 2 are ok will be difficult to fix point 3 above due to the fact that the Sender (the value in Return-Path header) is always different in quarantined Spam.

Marius.

[Anonymous]

Thanks for your reply, Marius!

Regarding your three points:

1) Exchange does not require authentication, because up to 3 days ago it was the official smtpd server, receiving mail from the Internet.
Authentication on port 25 is available, and it is a MUST, but only if you want to use Exchange as a relay (mail from internal senders to inet must come from authenticated senders)

2) well, if you see my messages above, authentication was correct in the "postmaster@mydomain.com" case, but wrong in the "user1@mydomain.com -> user2@mydomain.com" case. And the second case was impossible to fix, because even adding a

user1@mydomain.com    USERNAME:PASSWORD

to sasl_passwd, would have solved the "user1@mydomain.com -> user2@mydomain.com" case, but would have created a problem for the "user1@mydomain.com -> inet" case, since USERNAME:PASSWORD would have been used to authenticate on the smarthost and would have failed

3) this could probably be solved playing with the Send As privilege at AD level for some selected Exchange users (as I did for the user authenticating on behalf of postmaster), but I think that such games are better left unplayed whenever possible :-)

I think that the problem here is that enabling smarthost in Scrollout adds

smtp_sasl_auth_enable=yes

to main.cf, thus forcing Postfix SMTP's client to use authentication even where it's not really needed (i.e., when connecting to Exchange).

So my current solution, disabling authentication at the transport level for the transport which connects to Exchange, seems to me the most "right", since it is a nice way to undo smtp_sasl_auth_enabled=yes where it's not needed, while keeping it globally active for dealing with the smarthost(s).

I've not yet tested whether master.cf gets rewritten when Scrollout's configuration is changed via GUI, but since the modification is minimal, I can redo it easily.

After the first day, I've not seen anything strange in logs, and no message stuck in queue because of failed SASL auth.

Meanwhile, Scrollout is more and more winning my liking, and I plan to test it in another place where I work after the holidays :-)

Thanks again!