Hi list, I have been getting the following types of log messages
Jan 30 08:22:33 ndgonline postfix/smtpd[30538]: NOQUEUE: reject: RCPT from unknown[71.46.229.50]: 450 4.7.1 Client host rejected: cannot find your hostname, [71.46.229.50]; from=DWoodman@orangebankfl.com to=rkampen@ndgonline.net proto=ESMTP helo=<mail.floridianbank.com>
a rdns check shows all is well with 71.46.229.50 - it belongs to the from senders domain name.
;; ANSWER SECTION: 50.229.46.71.in-addr.arpa. 777 IN PTR mail2.orangebankfl.com.
It seems it is being rejected due to the helo domain name - which does not have a correct rdns.
My problem is that I do not specify the helo check??
this is the relevant portion of main.cf
<snip> smtpd_helo_required = yes smtpd_delay_reject = yes #added 20090410 strict_rfc821_envelopes = yes smtpd_helo_restrictions = permit_mynetworks, reject_non_fqdn_helo_hostname, reject_invalid_helo_hostname, permit
smtpd_sender_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_non_fqdn_sender, reject_unknown_client, reject_unauthenticated_sender_login_mismatch, permit
smtpd_sender_login_maps = hash:/etc/postfix/smtpd_sender_login_map
smtpd_client_restrictions = check_client_access hash:/etc/postfix/access
smtpd_recipient_restrictions = reject_unauth_pipelining, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, check_sender_access hash:/etc/postfix/sender_access, check_recipient_access hash:/etc/postfix/roleaccount_exceptions, check_helo_access pcre:/etc/postfix/helo_checks, reject_rbl_client sbl-xbl.spamhaus.org, reject_rbl_client cbl.abuseat.org, reject_rbl_client dul.dnsbl.sorbs.net, check_policy_service unix:postgrey/socket, permit
# reject_unauthenticated_sender_login_mismatch
smtpd_sasl_auth_enable = yes smtpd_sasl_security_options = noanonymous #, noplaintext broken_sasl_auth_clients = yes
</snip>
so no reject_unknown_helo_hostname check - so why is it throwing them out?
Thanks for anyone's insight.
On 02/02/2012 11:01 AM, Rob Kampen wrote:
Hi list, I have been getting the following types of log messages
Jan 30 08:22:33 ndgonline postfix/smtpd[30538]: NOQUEUE: reject: RCPT from unknown[71.46.229.50]: 450 4.7.1 Client host rejected: cannot find your hostname, [71.46.229.50]; from=DWoodman@orangebankfl.com to=rkampen@ndgonline.net proto=ESMTP helo=<mail.floridianbank.com>
a rdns check shows all is well with 71.46.229.50 - it belongs to the from senders domain name.
;; ANSWER SECTION: 50.229.46.71.in-addr.arpa. 777 IN PTR mail2.orangebankfl.com.
It seems it is being rejected due to the helo domain name - which does not have a correct rdns.
My problem is that I do not specify the helo check??
this is the relevant portion of main.cf
<snip> smtpd_helo_required = yes smtpd_delay_reject = yes #added 20090410 strict_rfc821_envelopes = yes smtpd_helo_restrictions = permit_mynetworks, reject_non_fqdn_helo_hostname, reject_invalid_helo_hostname, permit
smtpd_sender_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_non_fqdn_sender, reject_unknown_client, reject_unauthenticated_sender_login_mismatch, permit
smtpd_sender_login_maps = hash:/etc/postfix/smtpd_sender_login_map
smtpd_client_restrictions = check_client_access hash:/etc/postfix/access
smtpd_recipient_restrictions = reject_unauth_pipelining, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, check_sender_access hash:/etc/postfix/sender_access, check_recipient_access hash:/etc/postfix/roleaccount_exceptions, check_helo_access pcre:/etc/postfix/helo_checks, reject_rbl_client sbl-xbl.spamhaus.org, reject_rbl_client cbl.abuseat.org, reject_rbl_client dul.dnsbl.sorbs.net, check_policy_service unix:postgrey/socket, permit
# reject_unauthenticated_sender_login_mismatch
smtpd_sasl_auth_enable = yes smtpd_sasl_security_options = noanonymous #, noplaintext broken_sasl_auth_clients = yes
</snip>
so no reject_unknown_helo_hostname check - so why is it throwing them out?
mail.floridianbank.com != mail2.floridianbank.com
culprit => reject_non_fqdn_helo_hostname
but I would not disable it.
On Thu, Feb 02, 2012 at 11:01:52PM +1300, Rob Kampen wrote:
50.229.46.71.in-addr.arpa. 777 IN PTR mail2.orangebankfl.com.
However: % getent hosts mail2.orangebankfl.com. 71.43.202.234 mail2.orangebankfl.com
71.46.229.50 != 71.43.202.234
Senders DNS is broken. rDNS lookup validation is failing.
On 02/02/12 10:01, Rob Kampen wrote:
Hi list, I have been getting the following types of log messages
Jan 30 08:22:33 ndgonline postfix/smtpd[30538]: NOQUEUE: reject: RCPT from unknown[71.46.229.50]: 450 4.7.1 Client host rejected: cannot find your hostname, [71.46.229.50]; from=DWoodman@orangebankfl.com to=rkampen@ndgonline.net proto=ESMTP helo=<mail.floridianbank.com>
a rdns check shows all is well with 71.46.229.50 - it belongs to the from senders domain name.
;; ANSWER SECTION: 50.229.46.71.in-addr.arpa. 777 IN PTR mail2.orangebankfl.com.
It seems it is being rejected due to the helo domain name - which does not have a correct rdns.
No, the error is:
Client host rejected: cannot find your hostname, [71.46.229.50]
<snip>
smtpd_sender_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_non_fqdn_sender, reject_unknown_client, reject_unauthenticated_sender_login_mismatch, permit
and you have reject_unknown_client above.
Postfix is attempting a rDNS lookup against the client IP [71.46.229.50], it temp failed for whatever reason (not that uncommon) so the client is "unknown" and you rejected it accordingly.
See the Postfix documentation entry for more info:
reject_unknown_client_hostname (with Postfix < 2.3: reject_unknown_client) Reject the request when 1) the client IP address->name mapping fails, 2) the name->address mapping fails, or 3) the name->address mapping does not match the client IP address. This is a stronger restriction than the reject_unknown_reverse_client_hostname feature, which triggers only under condition 1) above. The unknown_client_reject_code parameter specifies the response code for rejected requests (default: 450). The reply is always 450 in case the address->name or name->address lookup failed due to a temporary problem.
I would recommend removing reject_unknown_client from your smtpd_sender_restrictions.
Hope that helps.
On 2012-02-02 15:39, Ned Slider wrote:
I would recommend removing reject_unknown_client from your smtpd_sender_restrictions.
I would not recommend that, I would recommend you fix your DNS. If you have a lot of mail throughput perhaps run a caching-DNS server or proxy to improve performance and reduce timeouts.
On 02/02/12 15:44, Giles Coochey wrote:
On 2012-02-02 15:39, Ned Slider wrote:
I would recommend removing reject_unknown_client from your smtpd_sender_restrictions.
I would not recommend that, I would recommend you fix your DNS. If you have a lot of mail throughput perhaps run a caching-DNS server or proxy to improve performance and reduce timeouts.
What makes you think it's his DNS that is/was broken?
But yes, a caching name server is almost obligatory for anyone running a mail server.
There is a reason the default rejection code is 450 and that is because temporary failures in DNS lookups are not uncommon, otherwise it would be a permanent rejection. IMHO this setting is more likely to delay legitimate mail with temporary DNS issues, as is the case here, than it is to block spam. There are more reliable indicators of spam that are less likely to cause FPs than relying on a rDNS lookup.
On 02/02/2012 17:35, Ned Slider wrote:
On 02/02/12 15:44, Giles Coochey wrote:
On 2012-02-02 15:39, Ned Slider wrote:
I would recommend removing reject_unknown_client from your smtpd_sender_restrictions.
I would not recommend that, I would recommend you fix your DNS. If you have a lot of mail throughput perhaps run a caching-DNS server or proxy to improve performance and reduce timeouts.
What makes you think it's his DNS that is/was broken?
I didn't take much notice to the overall context of the error. The sender's DNS is broken, the sender may be the same organisation as the receiver.
But yes, a caching name server is almost obligatory for anyone running a mail server.
Agreed.
There is a reason the default rejection code is 450 and that is because temporary failures in DNS lookups are not uncommon, otherwise it would be a permanent rejection. IMHO this setting is more likely to delay legitimate mail with temporary DNS issues, as is the case here, than it is to block spam. There are more reliable indicators of spam that are less likely to cause FPs than relying on a rDNS lookup.
There are times when you might want to just receive anything on port 25, missing rDNS is a good indication of a bot. I don't use absolute rules myself for accepting or rejecting emails on my gateways, but rather a score based system.
However, the sender will have a large number of deferred messages in their queue if we assume that the missing rDNS is a global problem and their users will eventually be receiving warning messages and later bounces for a good proportion of emails they send. I don't see any reason to go out of my way to workaround their problem.
On 02/03/2012 06:35 AM, Ned Slider wrote:
On 02/02/12 15:44, Giles Coochey wrote:
On 2012-02-02 15:39, Ned Slider wrote:
I would recommend removing reject_unknown_client from your smtpd_sender_restrictions.
I think this will allow the mail through - but when I look at my logs just in the last week we have over 5400 rejects due to unknown client and only 24 of these are from this client - all the rest are junk.
My confusion is that a reverse lookup of the IP gives me the clients domain (dropping the mail(x) subdomain) thus I assumed it was the helo domain name - which does not have rDNS - that was causing the reject - maybe it was just a timing error. Also, as I run bind - it may be a cache error and I need to leave it for 24+ hours
Final question for the list - does anyone use "reject_unknown_client" - it has given me the most grief with legitimate clients that have poorly administered domains.
I would not recommend that, I would recommend you fix your DNS. If you have a lot of mail throughput perhaps run a caching-DNS server or proxy to improve performance and reduce timeouts.
we already run bind - the problem should not be temp timeouts. The domain with the problem is not under my control.
What makes you think it's his DNS that is/was broken?
But yes, a caching name server is almost obligatory for anyone running a mail server.
There is a reason the default rejection code is 450 and that is because temporary failures in DNS lookups are not uncommon, otherwise it would be a permanent rejection. IMHO this setting is more likely to delay legitimate mail with temporary DNS issues, as is the case here, than it is to block spam. There are more reliable indicators of spam that are less likely to cause FPs than relying on a rDNS lookup.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 02/02/2012 10:08 PM, Rob Kampen wrote:
Final question for the list - does anyone use "reject_unknown_client" - it has given me the most grief with legitimate clients that have poorly administered domains.
My restrictions are:
permit_mynetworks permit_sasl_authenticated reject_unknown_hostname permit_mx_backup reject_unauth_destination reject_non_fqdn_hostname reject_non_fqdn_sender reject_non_fqdn_recipient reject_unknown_sender_domain reject_rbl_client sbl.spamhaus.org dnsbl.sorbs.net
and I am very happy with them. SPAM is very limited, and false positives are rare. I usually send worning mail to the admin of the domain in question.
Rob Kampen wrote on Fri, 03 Feb 2012 10:08:09 +1300:
My confusion is that a reverse lookup of the IP gives me the clients domain (dropping the mail(x) subdomain) thus I assumed it was the helo domain name - which does not have rDNS - that was causing the reject - maybe it was just a timing error.
No, it wasn't, read the explanation of this check, see below. You may want to use reject_unknown_reverse_client_hostname instead. Actually, I've not been aware until now that it does more than checking the rDNS (or I had forgotten it in the meantime and had to be reminded :-).
reject_unknown_client_hostname (with Postfix < 2.3: reject_unknown_client) Reject the request when 1) the client IP address->name mapping fails, 2) the name->address mapping fails, or 3) the name->address mapping does not match the client IP address. This is a stronger restriction than the reject_unknown_reverse_client_hostname feature, which triggers only under condition 1) above. http://www.postfix.org/postconf.5.html
Final question for the list - does anyone use "reject_unknown_client" - it has given me the most grief with legitimate clients that have poorly administered domains.
I've been using the reject_unknown_client_hostname restriction on my own server(s) for years with no problems. But I'm not using it on client's servers. Looks like one day I knew what it does ;-) I think reject_unknown_client_hostname is a good restriction, but you may get too many "false" positives. There is no definitive RFC requirement that the mapping has to match. That's different for the simple rDNS lookup. I think it's defined in several RFCs (at least by loose interpretation) and also explained in every "mail server setup howto" and on Wikipedia. I usually point clients/admins to such a source and after a (not so long) while the sender mysteriously manages to have rDNS set up by his provider ... So, I would certainly recommend trying the less restrictive reject_unknown_reverse_client_hostname . As you pointed out lots of bots don't have rDNS, so they get rejected by this very effectively. And the false positive ratio is very low. Certainly lower for me than Sorbs (threw out Sorbs years ago).
Kai
On Fri, Feb 03, 2012 at 12:21:28PM +0100, Kai Schaetzl wrote:
many "false" positives. There is no definitive RFC requirement that the mapping has to match.
But it's a standard security feature (on Solaris NFS server it was added around 1996, I think). Without the match I could set my servers IP address to be "mail.google.com". No one should believe me unless a forward lookup matches. It is commonly considered "broken" for rDNS to return a value that doesn't match forward DNS.
false positive ratio is very low. Certainly lower for me than Sorbs (threw out Sorbs years ago).
I, personally, use zen.spamhaus.org
On Fri, Feb 3, 2012 at 7:01 AM, Stephen Harris lists@spuddy.org wrote:
many "false" positives. There is no definitive RFC requirement that the mapping has to match.
But it's a standard security feature (on Solaris NFS server it was added around 1996, I think). Without the match I could set my servers IP address to be "mail.google.com". No one should believe me unless a forward lookup matches. It is commonly considered "broken" for rDNS to return a value that doesn't match forward DNS.
If you say something is "broken", you should quote the RFC with the MUST requirement that it breaks. I don't think there is one for this. The forward and reverse naming control is delegated 2 different ways and may not be under the same person's control. It is also relatively common to have multi-homed hosts with the same name for multiple interfaces, or connections that go through NAT where the host doesn't even know what source address will appear on its connections.
On Fri, Feb 03, 2012 at 08:02:32AM -0600, Les Mikesell wrote:
On Fri, Feb 3, 2012 at 7:01 AM, Stephen Harris lists@spuddy.org wrote:
a forward lookup matches. ?It is commonly considered "broken" for rDNS to return a value that doesn't match forward DNS.
If you say something is "broken", you should quote the RFC with the MUST requirement that it breaks. I don't think there is one for this.
RFC 1912 section 2.1 http://tools.ietf.org/html/rfc1912 which says explicitly "Make sure your PTR and A records match."
Which leads to things like RFC 5451 section 2.4.3 ("iprev") http://tools.ietf.org/html/rfc5451#section-2.4.3
Regardless of what the RFCs may or may not say, rDNS is _untrusted_ without a forward lookup validation.
The forward and reverse naming control is delegated 2 different ways and may not be under the same person's control. It is also
Irrelevant. If I make my hosts rDNS claim it is "mail.google.com" then no one should believe me 'cos the A record for that domain points totally elsewhere. rDNS without forward DNS validation is _untrusted_ data, and if you're performing security checks without validating the data then you're doing it wrong. This is ancient knowledge; as I said, Sun patched Solaris NFS server to fix this gap over 15 years ago.
relatively common to have multi-homed hosts with the same name for multiple interfaces,
Not a problem; rDNS and A record matching can still occur in this case.
or connections that go through NAT where the hostdoesn't even know what source address will appear on its connections.
Not a problem; here it's the NAT address that matters and that needs working rDNS and A record matching.
I'd agree that expecting HELO to match the IP address is wrong, but I'm not asserting that. I don't care about packet _contents_, I merely care that DNS is configured in a manner that makes it trustable.
On 02/02/12 21:08, Rob Kampen wrote:
On 02/03/2012 06:35 AM, Ned Slider wrote:
On 02/02/12 15:44, Giles Coochey wrote:
On 2012-02-02 15:39, Ned Slider wrote:
I would recommend removing reject_unknown_client from your smtpd_sender_restrictions.
I think this will allow the mail through - but when I look at my logs just in the last week we have over 5400 rejects due to unknown client and only 24 of these are from this client - all the rest are junk.
Correct. I simply identified the problem and made a recommendation to fix it (i.e, prevent it from happening). As I said before there are more reliable ways to block spam than relying on correctly configured/working upstream DNS.
<snip>
Final question for the list - does anyone use "reject_unknown_client" - it has given me the most grief with legitimate clients that have poorly administered domains.
Hence my recommendation to remove it. But it's your server and your mail flow, ymmv :-)
-
Giles Coochey -
Kai Schaetzl -
Les Mikesell -
Ljubomir Ljubojevic -
Ned Slider -
Rob Kampen -
Stephen Harris