Problem with Postfix milter and SPF HELO from localhost

[timber]

Hi!

I recently added DKIM to my Plesk 12.0.8 #10 setup since it is essential to not have my emails being more likely to go into Gmail user's spam folders. That is when I noticed an issue with SPF not allowing any HELO messages from localhost. This clashes with the way postfix's cleanup server works (http://www.postfix.org/MILTER_README.html):

There's one small complication when using Milter applications for non-SMTP mail: there is no SMTP session. To keep Milter applications happy, the Postfix cleanup(8) server actually has to simulate the SMTP client CONNECT and DISCONNECT events, and the SMTP client EHLO, MAIL FROM, RCPT TO and DATA commands.
When new mail arrives via the sendmail(1) command line, the Postfix cleanup(8) server pretends that the mail arrives with ESMTP from "localhost" with IP address "127.0.0.1". The result is very similar to what happens with command line submissions in Sendmail version 8.12 and later, although Sendmail uses a different mechanism to achieve this result.

The point where it breaks is written into postfix/main.cf:


milter_protocol=6
non_smtpd_milters = inet:127.0.0.1:8891, inet:127.0.0.1:12768

With the opendkim daemon listening on port 8891 and psa-pc-remote on 12768.

The problem not only occurs with mail originated locally (e.g. php-scripts sending mail via Wordpress using sendmail) but also if a local mail recipient is configured to forward to an external email address. It doesn't happen with milter_protocol=2 but together with opendkim, the psa-pc-remote crashes with a segfault then (http://blog.matoski.com/articles/spf-dk-dkim-plesk-debian/). milter_protocol=6 is also the default for current postfix setups.

Anyway, during the milter action, mail is sent with a HELO message from localhost which is generally not allowed by Plesk's SPF implementation resulting in mail being bounced:
spf filter[18524]: Wrong HELO hostname: localhost

The best workaround I found so far is to take out psa-pc-remote for non_smtpd_milters but leave it in for smtpd_milters:
milter_default_action = accept
milter_protocol = 6
smtpd_milters = inet:127.0.0.1:8891, inet:127.0.0.1:12768
non_smtpd_milters = inet:127.0.0.1:8891


Another one is to leave psa-pc-remote in for non_smtpd_milters but disable SPF checking in the panel.

Since I believe the first workaround disables the new outgoing mail limitation and possibly other things, this is something the Plesk team should definitely look into in my opinion. Apparently, they already are but the fix has not arrived so far:
http://forum.parallels.com/showthre...mail-binary-are-blocked-because-of-wrong-HELO

reported to development (PPP-10678 for your reference)

Just thought this might be interesting to other users possibly running into this issue.

Kind regards

 

[RaúlS]

Same issue here.
I've been trying to solve it but I couldn't, so I decided to use the same workaround (remove psa-pc-remote from non_smtpd_milters) for the moment...
Thanks timber.

EDIT: if I do that I lose DKIM signature, so I have decided to keep DKIM and lose DomainKeys using milter_protocol=2

 

[timber]

EDIT: if I do that I lose DKIM signature, so I have decided to keep DKIM and lose DomainKeys using milter_protocol=2

Not sure if you confuse DKIM with DomainKeys? Plesk supports DomainKeys by default while you have to add DKIM support manually with the opendkim package.

There is no point in setting milter_protocol=2 if you use DKIM because it will crash psa-pc-remote making you loose all Plesk-related email filters like DomainKeys, SPF, Greylisting, etc. Instead, by using the first workaround (disabling psa-pc-remote for non_smtpd_milters) you keep all the important filters for mail sent to your server via SMTP. Only mail originated locally (e.g. by using the sendmail binary like many PHP scripts) will not be run through psa-pc-remote.

However, if you use DomainKeys with no DKIM, you can set milter_protocol=2 and not run into any "HELO localhost" issues with SPF at all. Somehow Postfix cleanup server does not simulate its own SMTP session in that mode.

Hope this makes it clearer a bit.

If I may add this, I find it hard to understand why Plesk supports the more or less obsolete DomainKeys instead of DKIM which is relied on by many popular mail services like Gmail, Yahoo and Outlook. Even though my emails were perfectly clean, my server was not blacklisted, and I had DomainKeys and SPF in place, a lot of my emails to Gmail were put into people's spam folders.

 

[RaúlS]

Hi,

I was facing the same "provider considers my emails spam" so I included all signing mechanisms (DomainKeys via Plesk and DKIM via opendkim) and I got:

The Port25 Solutions, Inc. team

==========================================================
Summary of Results
==========================================================
SPF check: pass
DomainKeys check: pass
DKIM check: pass
Sender-ID check: pass
SpamAssassin check: ham

But yesterday I started to face problems with the email accounts which were being forwarded.

I tried your workaround and forwarding was working fine but DKIM ceased to work so I decided to restore milter_protocol = 2 and:

==========================================================
Summary of Results
==========================================================
SPF check: pass
DomainKeys check: neutral
DKIM check: pass
Sender-ID check: pass
SpamAssassin check: ham

I have lost DomainKeys signing but DKIM is still working and I have no forwarding issues, so I will maintain this workaround while a solution is developed (as you say DomainKeys is quite obsolete...).

EDIT:
OK, I think I got it.
I had:
milter_default_action = accept
milter_protocol = 6
smtpd_milters = inet:127.0.0.1:8891, inet:127.0.0.1:12768
non_smtpd_milters = $smtpd_milters
where:
8891 = dkim service
12768 = psa-pc-remote service (domainkeys signing and others)
everything was working fine but two days ago forwarding ceased to work with the "Wrong HELO hostname: localhost" messages and accounts stopped forwarding with a bounced "Undelivered Mail Returned to Sender" mail as response
changing protocol to 2 produces that postfix cannot connect to psa-pc-remote, losing DomainKeys signing but forwarding works
finally i have configured:
milter_protocol = 6
smtpd_milters = inet:127.0.0.1:8891, inet:127.0.0.1:12768
non_smtpd_milters = inet:127.0.0.1:8891
as you were recommending and I have both DKIM and DomainKeys signature and fowarding is working fine

Thanks again!

 

[Vito DonatoC]

Same problem here!

http://forum.parallels.com/showthre...-of-wrong-HELO&p=745722&viewfull=1#post745722

We used workaraound n.1 of timber (removed psa-pc-remote from non_smtpd_milters).
But in this way we disable every important plesk filter (including DomainKey signature) in the server-side generated mails.

We think the Plesk team should look into and solve definitely this problem.
Thanks!

 

[Kai_Schraps]

I got the same problem ... but there are two solutions, guys:

First:
-----
Stop the Plesk Milter Service in Plesk Panel and install the greylisting package for postfix (in example for debian)
apt-get install postgrey
in the Postfix main.cf delete the entry 'inet:127.0.0.1:12768' at 'non_smtpd_milters' and 'smtpd_milters'
and add to "smtpd_recipient_restrictions" the following entry:
check_policy_service inet:127.0.0.1:60000 where the Port 60000 is the standard port.
I have changed the port and configuration for my own purposes in /etc/default/postgrey to
POSTGREY_OPTS="--inet=10023 --delay=120 --max-age=30"
Restart postgrey with 'service postgrey restart' and reload postfix with 'service postfix reload' et voila ... you have a running stable greylisting filter outside from plesk.

P.S.: This stops the whole anti-spam stuff from plesk, but I suggest to have a look at Amavis (in my configuration in combination with ClamAV and SpamAssassin), this is a really good working Anti-Spam and Anti-Virus Protection System. With this, I have no, I repeat, NO spam and no virus mails ever since installing these stuff.

http://www.ijs.si/software/amavisd/

Have a look at my logfile:

Oct 30 04:28:40 f050 postfix/smtpd[8853]: connect from account.parallels.com[199.115.104.179]
Oct 30 04:28:42 f050 postgrey[30621]: action=pass, reason=triplet found, client_name=account.parallels.com, client_address=199.115.104.179, sender=[email protected], recipient=[email protected]
Oct 30 04:28:42 f050 postgrey[30621]: cleaning up old logs...
Oct 30 04:28:42 f050 postfix/smtpd[8853]: 185CF1E405D3: client=account.parallels.com[199.115.104.179]
Oct 30 04:28:42 f050 postfix/cleanup[8857]: 185CF1E405D3: message-id=<[email protected]>
Oct 30 04:28:42 f050 postfix/qmgr[12646]: 185CF1E405D3: from=<[email protected]>, size=6555, nrcpt=1 (queue active)
Oct 30 04:28:42 f050 postfix/smtpd[8853]: disconnect from account.parallels.com[199.115.104.179]
Oct 30 04:28:47 f050 postfix/smtpd[8861]: connect from localhost[127.0.0.1]
Oct 30 04:28:47 f050 postfix/smtpd[8861]: 882F31E40931: client=localhost[127.0.0.1], orig_queue_id=185CF1E405D3, orig_client=account.parallels.com[199.115.104.179]
Oct 30 04:28:47 f050 postfix/cleanup[8857]: 882F31E40931: message-id=<[email protected]>
Oct 30 04:28:47 f050 postfix/smtpd[8861]: disconnect from localhost[127.0.0.1]
Oct 30 04:28:47 f050 postfix/qmgr[12646]: 882F31E40931: from=<[email protected]>, size=7061, nrcpt=1 (queue active)
Oct 30 04:28:47 f050 amavis[20326]: (20326-05) Passed CLEAN {RelayedInbound}, [199.115.104.179]:44145 [199.115.104.179] <[email protected]> -> <[email protected]>, Queue-ID: 185CF1E405D3, Message-ID: <[email protected]>, mail_id: sbikWkIp-_wk, Hits: -0.787, size: 6537, queued_as: 882F31E40931, 5113 ms
Oct 30 04:28:47 f050 postfix/smtp[8858]: 185CF1E405D3: to=<[email protected]>, relay=127.0.0.1[127.0.0.1]:10024, delay=5.8, delays=0.62/0.03/0/5.1, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 882F31E40931)
Oct 30 04:28:47 f050 postfix/qmgr[12646]: 185CF1E405D3: removed
Oct 30 04:28:47 f050 postfix-local[8863]: postfix-local: from=[email protected], to=[email protected], dirname=/var/qmail/mailnames
Oct 30 04:28:47 f050 postfix/pipe[8862]: 882F31E40931: to=<[email protected]>, relay=plesk_virtual, delay=0.18, delays=0.06/0.01/0/0.1, dsn=2.0.0, status=sent (delivered via plesk_virtual service)
Oct 30 04:28:47 f050 postfix/qmgr[12646]: 882F31E40931: removed
Oct 30 04:32:03 f050 postfix/anvil[8855]: statistics: max connection rate 1/60s for (smtp:199.115.104.179) at Oct 30 04:28:40
Oct 30 04:32:03 f050 postfix/anvil[8855]: statistics: max connection count 1 for (smtp:199.115.104.179) at Oct 30 04:28:40
Oct 30 04:32:03 f050 postfix/anvil[8855]: statistics: max cache size 1 at Oct 30 04:28:40

Or this with a spam mail has been found earlier without postgrey:

Oct 28 17:41:47 f050 postfix/smtpd[5393]: connect from host213.200-59-11.cotelcam.net.ar[200.59.11.213]
Oct 28 17:41:48 f050 postfix/smtpd[5393]: 9BFC61E4092E: client=host213.200-59-11.cotelcam.net.ar[200.59.11.213]
Oct 28 17:41:49 f050 postfix/cleanup[5398]: 9BFC61E4092E: message-id=<[email protected]>
Oct 28 17:41:52 f050 postfix/qmgr[8479]: 9BFC61E4092E: from=<[email protected]>, size=25723, nrcpt=1 (queue active)
Oct 28 17:41:54 f050 postfix/smtpd[5393]: disconnect from host213.200-59-11.cotelcam.net.ar[200.59.11.213]
Oct 28 17:41:57 f050 amavis[3700]: (03700-14) Blocked SPAM {NoBounceInbound,Quarantined}, [200.59.11.213]:4835 [200.59.11.213] <[email protected]> -> <[email protected]>, quarantine: B/spam-BMVKkAfnWW0n.gz, Queue-ID: 9BFC61E4092E, Message-ID: <[email protected]>, mail_id: BMVKkAfnWW0n, Hits: 17.844, size: 25706, 4958 ms
Oct 28 17:41:57 f050 postfix/smtp[5400]: 9BFC61E4092E: to=<[email protected]>, relay=127.0.0.1[127.0.0.1]:10024, delay=8.9, delays=3.9/0.02/0/5, dsn=2.5.0, status=sent (250 2.5.0 Ok, id=03700-14, DISCARD(bounce.suppressed))
Oct 28 17:41:57 f050 postfix/qmgr[8479]: 9BFC61E4092E: removed
Oct 28 17:45:14 f050 postfix/anvil[5395]: statistics: max connection rate 1/60s for (smtp:200.59.11.213) at Oct 28 17:41:47
Oct 28 17:45:14 f050 postfix/anvil[5395]: statistics: max connection count 1 for (smtp:200.59.11.213) at Oct 28 17:41:47
Oct 28 17:45:14 f050 postfix/anvil[5395]: statistics: max cache size 1 at Oct 28 17:41:47

Second:
Just uncheck the server-wide graylisting-spamfilter in the plesk panel and install 'postgrey' as mentioned above.

 

[IsmaeelA]

Oh, thank you so much @timber
This workaround saves me, the psa-pc-remote is keep crashing with (milter_protocol = 2).
The psa-pc-remote was going down and start up each 5 minutes, the watchdog was sending me notifications about that. It's really annoying.

After I did this workaround and change (milter_protocol = 2) to (milter_protocol = 6), the issue was solved.

I think Parallels Team should do something about this.

Thanks.

 

[johnrdorazio]

finally i have configured:
milter_protocol = 6
smtpd_milters = inet:127.0.0.1:8891, inet:127.0.0.1:12768
non_smtpd_milters = inet:127.0.0.1:8891
as you were recommending and I have both DKIM and DomainKeys signature and fowarding is working fine

This did the trick for me! I had set up DKIM, and I had to change this:

non_smtpd_milters = $smtpd_milters

to this:

non_smtpd_milters = inet:127.0.0.1:8891

Setting it as you suggested has now fixed the php mail scripts, they are correctly sending emails again.