Spam protection based on DNS blackhole list: Still has to be off

[gerryb]

Since 8.4, and 8.6 has not fixed, spam protection based on DNS blackhole lists blocks authenticated emails for relay. This is not the correct behavour. SMPT connections coming in to local addresses should be checked against spamhous data bases and blocked if on their list, but spamhous DNS blackhole list should not be looked up from clients who have logged logged in and authenticated themselves, and simply sending out their own originating email.

Spamhous sensibly lists most ISP home connection IPs as blackholes, as these are not expected to relay email...if they are doing so, they are likely to have been hi-jacked. However home/office clients who log in and are authenticated must be allowed to send emails.

The only way to allow clients to send emails at present is to turn off on spam protection based on DNS blackhole lists. Asking ISPs to get spamhous to take off their IPs is not sensible, and they may well refuse.

Q: What is the fix that allows authenticated SMTP connections not to be looked up by the spam protection based on DNS blackhole lists? (That is putting the system back to how it worked in versions prior to 8.4)

Thanks, Gerard Bulger

 

[akxak]

You cannot solve this problem as such and it is NOT a problem of Plesk.

The check against the dns blacklist is done at the first connection attempt of the sender. At that time, no authentication happened, so it cannot be determined whether the user can authenticate himself or not.

Tell your users to use the "subscription" port 587 instead of the standard smtp port 25 which is not checked agains the blacklists.

 

[intosh]

You cannot solve this problem as such and it is NOT a problem of Plesk.

- it's Plesk fault as thirst thing user mail client do is authenticate before sending and then is set to be RELAYCLIENT. RELAYCLIENTS mast not be checked against DNS blackhole lists. This is bug in Plesk!

 

[akxak]

You should perhaps have a closer look on HOW DNS blacklists work... to ensure speed, the list is checked first. That's why eg. the submission port exists.

And again, although not satisfied with Plesk at all, for this, Plesk cannot be blamed.

 

[intosh]

Speed has nothing to do with it.

When user is authenticated and is RELAYCIENT no query to DNS blacklist is necessary - that's speed.

The way you describe it works, in situation when all mail servers use DNS blacklists one of blacklisted IPs will not be able to send email in any way, no matter he is valid user and has email account on the server.

 

[intosh]

One more thing. DNS blacklists, as used by mail servers, are to limit spam not their own users emails.

 

[akxak]

@intosh

It seems to be very difficult to get familiar with software and how this software is working as well as understanding how the smtp protocol works.

Plesk uses Qmail for mail processing. Qmail as such does not support DNS blacklisting.

SMTP Authentication is a part of the SMTP protocol, QMail would need to implement DNS blacklisting support to allow the cancelation of a SMTP dialog for DNS blacklisting. As QMail does NOT, swsoft would need to patch and extend the present QMail.

Therefore, the DNS blacklisting check is done with the first connect attempt of a sending system. Which leads to the effect that also clients which could authenticate, are blocked out.

That's why the "submission port" has been introduced and was meanwhile raised to RFC status. Plesk does support the submission port. And using this, the clients can send mails as DNS blacklisting is not performed on that port.

Regarding perfomance, you should have a closer look on how this works. The present solution needs one dns check to identify whether the sending system is accepted or not. This way it is done not only within Plesk but within all systems using QMail.

Moving this into the SMPT protocol handshake, the handshake itself needs to be initiated and properly terminated to tell the sending system that the mail was NOT accepted.

Again, read and understand how QMail works... read and understand how the submission port works... after reading and understand tell your users... if you did not understand, got to the beginning and start again.

Repeating complaints without the necessary background knowledge does help nobody here...

Last answer...

 

[intosh]

I guess it all depends on implementation [ see: http://qmail-dnsbl.sourceforge.net/ ] - but if it works in Plesk like you described it I can't see much use for this future, maybe if all your users are in LAN network.

Anyway idea to block all IPs in RBL without letting them authenticate first, sounds like crazy for me.

 

[atomicturtle]

The solution to that was the creation of the submission standard, which is to enforce authenticated relaying only. It solves a lot of other problems in the process as well. Generally ISP's will block outbound traffic on port 25 for anti-spam reasons, using submission on 587 gets around that safely. This manifests itself in your users contacting you because they cant send mail, wasting both your time and theirs. If you want the lowest cost solution, convert them all to using it.

 

[akxak]

@intosh

Again, read and understand how the submission port works... after reading and understanding tell your users... if you did not understand, got to the beginning and start again.

 

[intosh]

akxak - I do understand how submission port works, this is nice idea but:

- which mail client supports it in default config or at least has a switch in configuration like "Use submission port when sending email when available" (no, typing magic port number in advanced settings is not an option)?

- where in Plesk CP, the domain owner can get info that this is supported on this server and required in fact when DNS blacklisting is enabled?

- telling users... well, please tell 4000 users to reconfigure their mail client today to use submission port (hey this is still small server)

 

[atomicturtle]

You can enable the submission port under server->mail->submission port (its a checkbox)

 

[gerryb]

Gosh I did not realise I would set off such a correspondence. Plesk's desktop screen does not make it clear at all that one has to use port 587 to use DNS blacklists on port 25. Furthermore prior to 8.4 Plesk and DNS blacklisting worked fine on port 25.....blacklisted except those with authenticated logins.

It looks as if I will be having to used 587 which is a good idea for all sorts of other reasons.

Thanks. Gerry