reject_non_fqdn_helo_hostname
in [Postfix]
|
From: Stan Hoeppner on 11 Jun 2010 10:12 Does Postfix consider "architettobellucci.com" an FQDN? I've always understood an FQDN as requiring all 3 of host.domain.tld. If my understanding of FQDN is correct, then a spam slipped through that I believe should have been rejected by reject_non_fqdn_helo_hostname. What have I configured incorrectly that allowed this spam through? Log transcript of transaction: Jun 11 02:49:55 greer postfix/smtpd[9598]: warning: 95.110.133.74: hostname host74-133-110-95.serverdedicati.aruba.it verification failed: Name or service not known Jun 11 02:49:55 greer postfix/smtpd[9598]: connect from unknown[95.110.133.74] Jun 11 02:49:56 greer postgrey: action=greylist, reason=new, client_name=unknown, client_address=95.110.133.74, sender=info(a)architettobellucci.com, recipient=stan(a)hardwarefreak.com Jun 11 02:49:56 greer postfix/smtpd[9598]: NOQUEUE: reject: RCPT from unknown[95.110.133.74]: 450 4.2.0 <stan(a)hardwarefreak.com>: Recipient address rejected: Greylisted, see http://postgrey.schweikert.ch/help/hardwarefreak.com.html; from=<info(a)architettobellucci.com> to=<stan(a)hardwarefreak.com> proto=ESMTP helo=<architettobellucci.com> Jun 11 02:49:56 greer postfix/smtpd[9598]: disconnect from unknown[95.110.133.74] Jun 11 02:50:57 greer postfix/anvil[9601]: statistics: max connection rate 1/60s for (smtp:95.110.133.74) at Jun 11 02:49:55 Jun 11 02:50:57 greer postfix/anvil[9601]: statistics: max connection count 1 for (smtp:95.110.133.74) at Jun 11 02:49:55 Jun 11 06:17:11 greer postfix/smtpd[10497]: warning: 95.110.133.74: hostname host74-133-110-95.serverdedicati.aruba.it verification failed: Name or service not known Jun 11 06:17:11 greer postfix/smtpd[10497]: connect from unknown[95.110.133.74] Jun 11 06:17:12 greer postgrey: action=pass, reason=triplet found, delay=12436, client_name=unknown, client_address=95.110.133.74, sender=info(a)architettobellucci.com, recipient=stan(a)hardwarefreak.com Jun 11 06:17:13 greer postfix/smtpd[10497]: 05D536C3E5: client=unknown[95.110.133.74] Jun 11 06:17:13 greer postfix/smtpd[10497]: disconnect from unknown[95.110.133.74] mail_version = 2.5.5 main.cf restrictions snippet since it'seasier to read than postconf -n output: smtpd_recipient_restrictions = permit_mynetworks reject_unauth_destination check_recipient_access hash:/etc/postfix/whitelist check_sender_access hash:/etc/postfix/whitelist check_client_access hash:/etc/postfix/whitelist check_client_access hash:/etc/postfix/blacklist check_client_access proxy:regexp:/etc/postfix/fqrdns.regexp check_client_access pcre:/etc/postfix/ptr-tld.pcre check_client_access proxy:${cidr}/countries check_client_access proxy:${cidr}/spammer check_client_access proxy:${cidr}/misc-spam-srcs reject_unknown_reverse_client_hostname reject_non_fqdn_sender reject_non_fqdn_helo_hostname reject_invalid_helo_hostname reject_unknown_helo_hostname reject_unlisted_recipient reject_rbl_client zen.spamhaus.org reject_rhsbl_client dbl.spamhaus.org reject_rhsbl_sender dbl.spamhaus.org reject_rhsbl_helo dbl.spamhaus.org check_policy_service inet:127.0.0.1:60000 postconf -n: alias_maps = hash:/etc/aliases append_dot_mydomain = no biff = no config_directory = /etc/postfix disable_vrfy_command = yes header_checks = pcre:/etc/postfix/header_checks inet_interfaces = all mailbox_command = /usr/lib/dovecot/deliver mailbox_size_limit = 0 message_size_limit = 10240000 mime_header_checks = pcre:/etc/postfix/mime_header_checks mydestination = hardwarefreak.com myhostname = greer.hardwarefreak.com mynetworks = 192.168.100.0/24 myorigin = hardwarefreak.com parent_domain_matches_subdomains = debug_peer_list smtpd_access_maps proxy_interfaces = 65.41.216.221 proxy_read_maps = $local_recipient_maps $mydestination $virtual_alias_maps $virtual_alias_domains $virtual_mailbox_maps $virtual_mailbox_domains $relay_recipient_maps $relay_domains $canonical_maps $sender_canonical_maps $recipient_canonical_maps $relocated_maps $transport_maps $mynetworks $sender_bcc_maps $recipient_bcc_maps $smtp_generic_maps $lmtp_generic_maps proxy:${cidr}/countries proxy:${cidr}/spammer proxy:${cidr}/misc-spam-srcs proxy:regexp:/etc/postfix/fqrdns.regexp readme_directory = /usr/share/doc/postfix recipient_bcc_maps = hash:/etc/postfix/recipient_bcc relay_domains = smtpd_banner = $myhostname ESMTP Postfix smtpd_helo_required = yes smtpd_recipient_restrictions = permit_mynetworks reject_unauth_destination check_recipient_access hash:/etc/postfix/whitelist check_sender_access hash:/etc/postfix/whitelist check_client_access hash:/etc/postfix/whitelist check_client_access hash:/etc/postfix/blacklist check_client_access proxy:regexp:/etc/postfix/fqrdns.regexp check_client_access pcre:/etc/postfix/ptr-tld.pcre check_client_access proxy:${cidr}/countries check_client_access proxy:${cidr}/spammer check_client_access proxy:${cidr}/misc-spam-srcs reject_unknown_reverse_client_hostname reject_non_fqdn_sender reject_non_fqdn_helo_hostname reject_invalid_helo_hostname reject_unknown_helo_hostname reject_unlisted_recipient reject_rbl_client zen.spamhaus.org reject_rhsbl_client dbl.spamhaus.org reject_rhsbl_sender dbl.spamhaus.org reject_rhsbl_helo dbl.spamhaus.org check_policy_service inet:127.0.0.1:60000 strict_rfc821_envelopes = yes virtual_alias_maps = hash:/etc/postfix/virtual Thanks. -- Stan
From: Wietse Venema on 11 Jun 2010 10:21 Stan Hoeppner: > Does Postfix consider "architettobellucci.com" an FQDN? I've always > understood an FQDN as requiring all 3 of host.domain.tld. If my understanding > of FQDN is correct, then a spam slipped through that I believe should have > been rejected by reject_non_fqdn_helo_hostname. What have I configured > incorrectly that allowed this spam through? Postfix's reject_non_fqdn_mumble features were intended to stop hosts that announce themselves by their netbios name (e.g., HELO OEMCOMPUTER). Postfix does not know where the registration boundaries are (.com and .org versus .co.uk and .ac.jp). Thus it uses the simplistic "does the name contain at least one dot". This is by no means bullet-proof with hosts (or domains) at the top level. Wietse
From: Stan Hoeppner on 11 Jun 2010 11:48 Wietse Venema put forth on 6/11/2010 9:21 AM: > Stan Hoeppner: >> Does Postfix consider "architettobellucci.com" an FQDN? I've always >> understood an FQDN as requiring all 3 of host.domain.tld. If my understanding >> of FQDN is correct, then a spam slipped through that I believe should have >> been rejected by reject_non_fqdn_helo_hostname. What have I configured >> incorrectly that allowed this spam through? > > Postfix's reject_non_fqdn_mumble features were intended to stop > hosts that announce themselves by their netbios name (e.g., HELO > OEMCOMPUTER). > > Postfix does not know where the registration boundaries are (.com > and .org versus .co.uk and .ac.jp). Thus it uses the simplistic > "does the name contain at least one dot". This is by no means > bullet-proof with hosts (or domains) at the top level. Thanks Wietse. For some reason I'd always assumed it was a little more sophisticated than that. But as you point out, and upon reflection, it seems it'd be pretty difficult to code this level of sophistication into the fqdn checking. -- Stan
From: Jeroen Geilman on 11 Jun 2010 13:38 On 06/11/2010 05:48 PM, Stan Hoeppner wrote: > Wietse Venema put forth on 6/11/2010 9:21 AM: > >> Stan Hoeppner: >> >>> Does Postfix consider "architettobellucci.com" an FQDN? I've always >>> understood an FQDN as requiring all 3 of host.domain.tld. If my understanding >>> of FQDN is correct, then a spam slipped through that I believe should have >>> been rejected by reject_non_fqdn_helo_hostname. What have I configured >>> incorrectly that allowed this spam through? >>> >> Postfix's reject_non_fqdn_mumble features were intended to stop >> hosts that announce themselves by their netbios name (e.g., HELO >> OEMCOMPUTER). >> >> Postfix does not know where the registration boundaries are (.com >> and .org versus .co.uk and .ac.jp). Thus it uses the simplistic >> "does the name contain at least one dot". This is by no means >> bullet-proof with hosts (or domains) at the top level. >> > > Thanks Wietse. For some reason I'd always assumed it was a little more > sophisticated than that. But as you point out, and upon reflection, it seems > it'd be pretty difficult to code this level of sophistication into the fqdn > checking. > As per DNS, any valid domain construct is, by definition, a valid hostname. So foo.com is just as fully-qualified as bar.baz.sub.foo.com - just a whole lot shorter. For this simple reason, it is not possible to determine whether a hostname is fully-qualified by its appearance alone. A more complete check is to use reject_unknown_helo_hostname - this verifies whether such a hostname actually *exists* in DNS, thus also fulfilling the non-fqdn-check's premise of testing for a fqdn (a DNS A record is, by definition, a fqdn.) However, it costs a little more, of course - it has to do the lookup. J.
|
Pages: 1 Prev: Too aggressive Next: db50 (DB11gR2) - Unsupported Berkeley DB version |