10

In the daily battle against SPAM, there have been several times when I've been tempted to heavily enforce DNS requirements from clients connecting from the wild Internet.

In detail, I would have added the reject_unknown_reverse_client_hostname setting within my smtpd_client_restrictions section, as in:

smtpd_client_restrictions = 
            permit_sasl_authenticated
            check_client_access hash:/etc/postfix/access 
            check_policy_service inet:127.0.0.1:4466
            reject_unknown_reverse_client_hostname
            reject_unauth_pipelining 

Anyway, I noted that when hitting such restriction, Postfix behaviour is quite "soft" as the default value for the unknown_client_reject_code is 450. Hence, client is invited to keep retrying.

While investigating for a 550 response, I met following statement, on the official Postfix documentation:

enter image description here

I'm absolutely not an expert about the whole RFC 5321, but as someone old enough to know RFC 821, I really don't see why, a 550 response instead of a 450, could impact my Postfix instance at the maximum SMTP level (breaking RFC compliance), expecially considering that in case of temporary errors, Postfix will stick with a 450 regardless of the explicit setting.

So, can someone help me understanding what's the problem with such a replacement?


P.S.: in the meantime, I ended with a "relaxed" restriction:

smtpd_client_restrictions = 
            permit_sasl_authenticated
            check_client_access hash:/etc/postfix/access 
            check_policy_service inet:127.0.0.1:4466
            warn_if_reject reject_unknown_reverse_client_hostname
            reject_non_fqdn_helo_hostname
            reject_unauth_pipelining 
            reject_invalid_helo_hostname 

1 Answer 1

13

I'll start with two practical answers

  1. The first and most obvious answer is that in a case where there's a temporary DNS error, a temporary bounce will allow the sender's mailserver to try again until the DNS error is fixed. In this case, a permanent bounce will block actual ham mail from reaching you.

  2. The second answer is that a great deal of spam is sent via botnet boxes that do not have any form of actual functional programs to send the mail. They will spray their junk once only, and won't try to re-send any messages whether said message gets a temporary or permanent error. So by using a temporary error, you are blocking a large percentage of the spam for good, but you're still allowing ham to try again. (This, by the way, is why greylisting still works and still catches a lot of spam.)

In addition to these ones, there are also an answer that bears more to the theory and the RFC

The RFC says in section 4.2.1. that:

A rule of thumb to determine whether a reply fits into the 4yz or the 5yz category (see below) is that replies are 4yz if they can be successful if repeated without any change in command form or in properties of the sender or receiver (that is, the command is repeated identically and the receiver does not put up a new implementation).

In the case of a reverse lookup failure, it would be possible for the message to be acceptable without any change in the message itself, provided only that the DNS error is fixed. Therefore, this should be a temporary error.

In a case where the message is not spam, the sending mailserver sysadmin may notice the error message and get the DNS problem fixed, so that the message can be delivered without the user having to intervene and re-send the message. And unless the user sending the email is also in charge of the mailserver and/or its DNS entries, even if they do get a permanent bounce directly, they won't be able to do anything with it - unlike e.g. the case of a misspelled address.

Of course, you are still always within your rights to reject any email for any reason.

4
  • I thought about DNS temporary problems but.... it seems they should not be an issue as... " The SMTP server always replies with 450 when the mapping failed due to a temporary error condition ". These should include temporary DNS lookup problems. Don't you? As for second point (BotNet, greylisting, etc.), it sounds reasonable: when clients don't implement a proper queuing mechanism, a 4XX response produce same effects of a 5XX one. Anyway I still miss why this have impacts at RFC level. Jun 6, 2015 at 16:50
  • 2
    @DamianoVerzulli It would apply when the mapping fails with an error, not when the DNS is misconfigured to return the wrong name, and it subsequently gets fixed. In any case, I've expanded a bit on the issues pertaining to the RFC.
    – Jenny D
    Jun 6, 2015 at 17:10
  • 1
    Thanks for pointing to proper RFC section. I'm focusing on this: "replies are 4yz if they can be successful if repeated WITHOUT ANY CHANGE in command form or in PROPERTIES of the SENDER or receiver". My first guess is that the DNS hostname of the client, as well as its reverse DNS mapping, are properties of the sender. Don't you? Otherwise I cannot see what could be a sender property. (BTW: please don't take my comments personally. I'm really interested in this discussion and really appreciate your points! Thanks for commenting!). Jun 6, 2015 at 17:40
  • 1
    @DamianoVerzulli The DNS hostname is not a property of the sending mailserver and cannot be changed within the mailserver configuration. It is controlled by the authoritative DNS server, which is usually not even the same server, much less part of the email server. Sometimes it's not even controlled within the same organization. (I'm not taking it personally - this is a discussion of facts, without any ad hominem arguments, there's nothing to take personally! I agree that it's very interesting and I don't think it's clear-cut, there's a case to be made for the other side too.)
    – Jenny D
    Jun 7, 2015 at 6:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .