reject_unknown_client_hostname and 450s

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

reject_unknown_client_hostname and 450s

@lbutlr
When reject_unknown_client_hostname triggers on an NXDOMAIN it returns a 550 error, which is great. When it triggers because there is no PTR record, it returns a 450 error, which is also great… except.

What I see is servers that connect hundreds of times, getting 450 errors and ignoring them and trying to send their spam again and again and again.

I have some IPs that have tried to connect hundreds of times to send a message that is always going to generate a 450 error since the host does not have a PTR record and never will. I have over 10,000 of these failures on an average day.

Does anyone have any suggestions? I am thinking about writing a fail2ban action for them that triggers after 5 or 10 attempts with a long ban, but I am not sure that's a good idea.

Or should I just stop worrying and figure the amount of resources being used is insignificant?

--
sometimes ascii is the best use of bandwidth... Tonya Engst

Reply | Threaded
Open this post in threaded view
|

Re: reject_unknown_client_hostname and 450s

Ansgar Wiechers
On 2013-06-30 LuKreme wrote:

> When reject_unknown_client_hostname triggers on an NXDOMAIN it returns
> a 550 error, which is great. When it triggers because there is no PTR
> record, it returns a 450 error, which is also great… except.
>
> What I see is servers that connect hundreds of times, getting 450
> errors and ignoring them and trying to send their spam again and again
> and again.
>
> I have some IPs that have tried to connect hundreds of times to send a
> message that is always going to generate a 450 error since the host
> does not have a PTR record and never will. I have over 10,000 of these
> failures on an average day.
>
> Does anyone have any suggestions? I am thinking about writing a
> fail2ban action for them that triggers after 5 or 10 attempts with a
> long ban, but I am not sure that's a good idea.
>
> Or should I just stop worrying and figure the amount of resources
> being used is insignificant?

I'd say fail2ban is the way to go about this. If you want to be on the
safe side, make the threshold somewhat higher and extend the lockout
period.

Regards
Ansgar Wiechers
--
"Abstractions save us time working, but they don't save us time learning."
--Joel Spolsky
Reply | Threaded
Open this post in threaded view
|

Re: reject_unknown_client_hostname and 450s

Wietse Venema
In reply to this post by @lbutlr
LuKreme:
> When reject_unknown_client_hostname triggers on an NXDOMAIN it
> returns a 550 error, which is great. When it triggers because there
> is no PTR record, it returns a 450 error, which is also great?
> except.

That is incorrect. The 450 code is for errors where lookup
failed (no result instead of "does not exist").

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: reject_unknown_client_hostname and 450s

Noel Jones-2
In reply to this post by @lbutlr
On 6/30/2013 3:12 AM, LuKreme wrote:
> When reject_unknown_client_hostname triggers on an NXDOMAIN it returns a 550 error, which is great. When it triggers because there is no PTR record, it returns a 450 error, which is also great… except.

What you're seeing is the PTR lookup fails with a temporary DNS
lookup error, which always results in a 450 deferral.

>
> What I see is servers that connect hundreds of times, getting 450 errors and ignoring them and trying to send their spam again and again and again.
>
> I have some IPs that have tried to connect hundreds of times to send a message that is always going to generate a 450 error since the host does not have a PTR record and never will. I have over 10,000 of these failures on an average day.
>
> Does anyone have any suggestions? I am thinking about writing a fail2ban action for them that triggers after 5 or 10 attempts with a long ban, but I am not sure that's a good idea.
>
> Or should I just stop worrying and figure the amount of resources being used is insignificant?

Just ignore them is usually the best action.

but if their DNS is slow to fail and they make lots of parallel
connections, they can tie up all your smtpd processes.  If that
happens, fail2ban is a good solution.


  -- Noel Jones
Reply | Threaded
Open this post in threaded view
|

Re: reject_unknown_client_hostname and 450s

Stan Hoeppner
In reply to this post by @lbutlr
On 6/30/2013 3:12 AM, LuKreme wrote:
> When reject_unknown_client_hostname triggers on an NXDOMAIN it returns a 550 error, which is great. When it triggers because there is no PTR record, it returns a 450 error, which is also great… except.
>
> What I see is servers that connect hundreds of times, getting 450 errors and ignoring them and trying to send their spam again and again and again.
>
> I have some IPs that have tried to connect hundreds of times to send a message that is always going to generate a 450 error since the host does not have a PTR record and never will. I have over 10,000 of these failures on an average day.
>
> Does anyone have any suggestions?

Hosts that have no PTR/rDNS are almost certainly end user broadband PCs.
 Which means the clients are likely spambots.  They ignore rejections,
and they do not retry.  They simply keep pumping out new connections.

If they're all currently being rejected, and are not tying up your
smtpds, then as Noel suggested, simply ignore it.  If single clients are
using concurrent connections and eating too many smtpds then fail2ban is
one option.  Postscreen is another.  Or...

Postfix allows 50 concurrent connections per client by default with a
max of 100 smtpds.  Set smtpd_client_connection_count_limit to something
like 10 and watch your log daily for a week or so to make sure you're
not burdening legit clients.  The proper value here, if any, depends on
your mail flow.  This will limit concurrent connections of all clients.

--
Stan

Reply | Threaded
Open this post in threaded view
|

Re: reject_unknown_client_hostname and 450s

@lbutlr
In reply to this post by Wietse Venema

On 30 Jun 2013, at 06:05 , Wietse Venema <[hidden email]> wrote:

> LuKreme:
>> When reject_unknown_client_hostname triggers on an NXDOMAIN it
>> returns a 550 error, which is great. When it triggers because there
>> is no PTR record, it returns a 450 error, which is also great?
>> except.
>
> That is incorrect. The 450 code is for errors where lookup
> failed (no result instead of "does not exist").

Does not exist is NXDOMAIN, right?

When the result is empty, like in this recent spammer:

$ dig -x 208.84.134.170 | grep -A1 ";; Q"
;; QUESTION SECTION:
;170.134.84.208.in-addr.arpa.   IN      PTR

postfix returns a 450. (Note, I'm not complaining about postfix's behavior)

This IP has been failing with a 450 for weeks, but there are many.

I've setup post screen recently, but I have turned off the 'deep' tests because those tests have issues with gmail and my relatively low volume.

--
You may be anti anti-spam-kook if: Despite having invented the FUSSP you
not only don't know the difference between the SMTP envelope and SMTP
headers; you doubt there is such a thing as the SMTP envelop because
email doesn't involve paper.

Reply | Threaded
Open this post in threaded view
|

Re: reject_unknown_client_hostname and 450s

Noel Jones-2
On 7/1/2013 5:05 PM, LuKreme wrote:

>
> On 30 Jun 2013, at 06:05 , Wietse Venema <[hidden email]> wrote:
>
>> LuKreme:
>>> When reject_unknown_client_hostname triggers on an NXDOMAIN it
>>> returns a 550 error, which is great. When it triggers because there
>>> is no PTR record, it returns a 450 error, which is also great?
>>> except.
>>
>> That is incorrect. The 450 code is for errors where lookup
>> failed (no result instead of "does not exist").
>
> Does not exist is NXDOMAIN, right?
>
> When the result is empty, like in this recent spammer:
>
> $ dig -x 208.84.134.170 | grep -A1 ";; Q"
> ;; QUESTION SECTION:
> ;170.134.84.208.in-addr.arpa.   IN      PTR
>
> postfix returns a 450. (Note, I'm not complaining about postfix's behavior)
>
> This IP has been failing with a 450 for weeks, but there are many.


http://www.postfix.org/postconf.5.html#unknown_client_reject_code