Understanding address verification
Having a problem understanding where my issue is with AV for this one (maybe more) domain. I see the following message for this unknown user where AV seems to be working, I only cache positives mx1# grep 8024C2E2BD /var/log/maillog Feb 24 08:33:45 mx1 postfix/cleanup[7752]: 8024C2E2BD: message-id=20120224133345.8024c2e...@mx1.webtent.net Feb 24 08:33:45 mx1 postfix/qmgr[73990]: 8024C2E2BD: from=double-bou...@mx1.webtent.net, size=271, nrcpt=1 (queue active) Feb 24 08:33:50 mx1 postfix/smtp[6812]: 8024C2E2BD: enabling PIX workarounds: disable_esmtp delay_dotcrlf for x.x.x.x[x.x.x.x]:25 Feb 24 08:33:55 mx1 postfix/smtp[6812]: 8024C2E2BD: to=tmia...@example.com, relay=x.x.x.x[x.x.x.x]:25, delay=10, delays=0.01/0.01/5.1/5, dsn=5.1.1, status=undeliverable-but-not-cached (host x.x.x.x[x.x.x.x] said: 550 5.1.1 User unknown (in reply to RCPT TO command)) Feb 24 08:34:00 mx1 postfix/qmgr[73990]: 8024C2E2BD: removed But unlike other domains that we transport for, I do not see the NOQUEUE reject log entries for this user address, I do see the deliveries for this user to localhost for scanning. Does this mean the address is in the verify db already as a good address? But then I would not understand why it would be checking again if that was the case. I do understand that AV will not reject if it can answer promptly, but still can't figure out why these messages are getting to the local scanner mx1# grep 83C1B2E2D6 /var/log/maillog Feb 24 08:33:45 mx1 postfix/smtpd[7085]: 83C1B2E2D6: client=rot.hbagac.com[70.99.240.229] Feb 24 08:33:45 mx1 postfix/cleanup[7806]: 83C1B2E2D6: message-id=1psq9w1e2.xplsni5lho6...@hbagac.com Feb 24 08:33:45 mx1 postfix/qmgr[73990]: 83C1B2E2D6: from=cordial...@hbagac.com, size=8570, nrcpt=1 (queue active) Feb 24 08:33:48 mx1 postfix/smtp[5906]: 83C1B2E2D6: to=tmia...@example.com, relay=127.0.0.1[127.0.0.1]:10024, delay=3.4, delays=0.47/0/0/2.9, dsn=2.7.1, status=sent (250 2.7.1 Ok, discarded, UBE, id=07851-02) Feb 24 08:33:48 mx1 postfix/qmgr[73990]: 83C1B2E2D6: removed Can someone help me understand what I have going on here with this domain? Here is my postfconf if it can shed some light ... mx1# postconf -n address_verify_map = btree:$data_directory/verify address_verify_negative_cache = no address_verify_poll_count = 1 alias_maps = hash:/usr/local/etc/postfix/aliases bounce_queue_lifetime = 1d broken_sasl_auth_clients = yes canonical_maps = ldap:/usr/local/etc/postfix/ldap/canonical.cf command_directory = /usr/local/sbin config_directory = /usr/local/etc/postfix content_filter = smtp-amavis:[127.0.0.1]:10024 daemon_directory = /usr/local/libexec/postfix data_directory = /var/db/postfix delay_warning_time = 4h disable_vrfy_command = yes html_directory = /usr/local/share/doc/postfix mail_owner = postfix mailbox_size_limit = 10240 mailq_path = /usr/local/bin/mailq manpage_directory = /usr/local/man maximal_backoff_time = 1000s maximal_queue_lifetime = 1d message_size_limit = 5120 mynetworks = 127.0.0.0/8, snip newaliases_path = /usr/local/bin/newaliases queue_directory = /var/spool/postfix readme_directory = /usr/local/share/doc/postfix relay_domains = ldap:/usr/local/etc/postfix/ldap/transport.cf sample_directory = /usr/local/etc/postfix sendmail_path = /usr/local/sbin/sendmail setgid_group = maildrop smtpd_banner = $myhostname ESMTP Mail Exchange smtpd_data_restrictions = reject_unauth_pipelining, permit smtpd_helo_restrictions = permit_mynetworks smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, check_client_access cidr:/usr/local/etc/postfix/relay_clients, check_client_access ldap:/usr/local/etc/postfix/ldap/relay_clients.cf, check_client_access hash:/usr/local/etc/postfix/client_checks, reject_unauth_destination, reject_non_fqdn_sender, reject_non_fqdn_recipient, check_helo_access hash:/usr/local/etc/postfix/helo_checks, check_recipient_access pcre:/usr/local/etc/postfix/recipient_checks.pcre, check_recipient_access ldap:/usr/local/etc/postfix/ldap/verification.cf, reject_rbl_client zen.spamhaus.org, permit smtpd_sasl_auth_enable = yes smtpd_sasl_authenticated_header = yes smtpd_sasl_local_domain = $myhostname smtpd_sasl_path = smtpd smtpd_sasl_security_options = noanonymous smtpd_sender_restrictions = permit_mynetworks check_sender_access hash:/usr/local/etc/postfix/sender_access reject_unknown_sender_domain check_sender_access ldap:/usr/local/etc/postfix/ldap/verification-sender.cf smtpd_tls_CAfile = /usr/local/etc/postfix/cacert.pem smtpd_tls_cert_file = /usr/local/etc/postfix/mx1-cert.pem smtpd_tls_key_file = /usr/local/etc/postfix/mx1-key.pem smtpd_tls_security_level = may smtpd_use_tls = yes transport_maps = ldap:/usr/local/etc/postfix/ldap/transport.cf unknown_local_recipient_reject_code = 550 unverified_recipient_reject_code = 550 unverified_sender_reject_code = 550 Thank you.
Re: Understanding address verification
Robert Fitzpatrick: (maybe more) domain. I see the following message for this unknown user where AV seems to be working, I only cache positives ... Feb 24 08:33:55 mx1 postfix/smtp[6812]: 8024C2E2BD: to=tmia...@example.com, relay=x.x.x.x[x.x.x.x]:25, delay=10, delays=0.01/0.01/5.1/5, dsn=5.1.1, status=undeliverable (host x.x.x.x[x.x.x.x] said: 550 5.1.1 User unknown (in reply to RCPT TO command)) Feb 24 08:34:00 mx1 postfix/qmgr[73990]: 8024C2E2BD: removed But unlike other domains that we transport for, I do not see the NOQUEUE reject log entries for this user address, I do see the deliveries for If you don't save the probe result, then the result is thrown away. Telepathic computing is not yet commercially available. Wietse
Re: Understanding address verification
Robert Fitzpatrick: On 2/24/2012 2:44 PM, Wietse Venema wrote: Robert Fitzpatrick: (maybe more) domain. I see the following message for this unknown user where AV seems to be working, I only cache positives ... Feb 24 08:33:55 mx1 postfix/smtp[6812]: 8024C2E2BD: to=tmia...@example.com, relay=x.x.x.x[x.x.x.x]:25, delay=10, delays=0.01/0.01/5.1/5, dsn=5.1.1, status=undeliverable (host x.x.x.x[x.x.x.x] said: 550 5.1.1 User unknown (in reply to RCPT TO command)) Feb 24 08:34:00 mx1 postfix/qmgr[73990]: 8024C2E2BD: removed But unlike other domains that we transport for, I do not see the NOQUEUE reject log entries for this user address, I do see the deliveries for If you don't save the probe result, then the result is thrown away. Telepathic computing is not yet commercially available. Thanks, yes, I understand why it is doing AV. What I don't understand is how come another message to the same recipient around the same time gets delivered to localhost for scanning. Your configuration throws away negative probe results. Therefore, negative probe results never block mail. Wietse
Re: Understanding address verification
Wietse Venema: Robert Fitzpatrick: On 2/24/2012 2:44 PM, Wietse Venema wrote: Robert Fitzpatrick: (maybe more) domain. I see the following message for this unknown user where AV seems to be working, I only cache positives ... Feb 24 08:33:55 mx1 postfix/smtp[6812]: 8024C2E2BD: to=tmia...@example.com, relay=x.x.x.x[x.x.x.x]:25, delay=10, delays=0.01/0.01/5.1/5, dsn=5.1.1, status=undeliverable (host x.x.x.x[x.x.x.x] said: 550 5.1.1 User unknown (in reply to RCPT TO command)) Feb 24 08:34:00 mx1 postfix/qmgr[73990]: 8024C2E2BD: removed But unlike other domains that we transport for, I do not see the NOQUEUE reject log entries for this user address, I do see the deliveries for If you don't save the probe result, then the result is thrown away. Telepathic computing is not yet commercially available. Thanks, yes, I understand why it is doing AV. What I don't understand is how come another message to the same recipient around the same time gets delivered to localhost for scanning. Your configuration throws away negative probe results. Therefore, negative probe results never block mail. Additionally, when a previous probe result is cached, Postfix will attempt to refresh that before it expires. The purpose is to avoid delays that are visible to the SMTP client. There is also is some logic to prevent a negative probe result from replacing a positive result. This is needed because Postfix will try to refresh a probe result before it expires. Wietse
Re: Understanding address verification
On 2/24/2012 3:40 PM, Wietse Venema wrote: Robert Fitzpatrick: On 2/24/2012 2:44 PM, Wietse Venema wrote: Robert Fitzpatrick: (maybe more) domain. I see the following message for this unknown user where AV seems to be working, I only cache positives ... Feb 24 08:33:55 mx1 postfix/smtp[6812]: 8024C2E2BD: to=tmia...@example.com, relay=x.x.x.x[x.x.x.x]:25, delay=10, delays=0.01/0.01/5.1/5, dsn=5.1.1, status=undeliverable (host x.x.x.x[x.x.x.x] said: 550 5.1.1 User unknown (in reply to RCPT TO command)) Feb 24 08:34:00 mx1 postfix/qmgr[73990]: 8024C2E2BD: removed But unlike other domains that we transport for, I do not see the NOQUEUE reject log entries for this user address, I do see the deliveries for If you don't save the probe result, then the result is thrown away. Telepathic computing is not yet commercially available. Thanks, yes, I understand why it is doing AV. What I don't understand is how come another message to the same recipient around the same time gets delivered to localhost for scanning. Your configuration throws away negative probe results. Therefore, negative probe results never block mail. That is the part I didn't understand. What exactly triggers the other rejections I see with NOQUEUE? I thought each message would be rejected as an unverified address if not found in the verify db. And telling Postfix not to keep negative probes only meant that the downstream server would be probed every time an address is seen. Thanks again, I really appreciate you helping me get my head around how this works.
Re: Understanding address verification
On 2/24/2012 4:17 PM, Wietse Venema wrote: There is also is some logic to prevent a negative probe result from replacing a positive result. This is needed because Postfix will try to refresh a probe result before it expires. Just read this after my last post. Perhaps this explains, the address is in the cache as positive and not expired. That would be why I don't see rejects. But why do I see the AV probe again each time the address comes in? Thanks again
Re: Understanding address verification
Robert Fitzpatrick: On 2/24/2012 4:17 PM, Wietse Venema wrote: There is also is some logic to prevent a negative probe result from replacing a positive result. This is needed because Postfix will try to refresh a probe result before it expires. Just read this after my last post. Perhaps this explains, the address is in the cache as positive and not expired. That would be why I don't see rejects. But why do I see the AV probe again each time the address comes in? That is explained in my two sentences above. I am not a pervert who has a better explanation but refuses to share it. Wietse
Re: Understanding address verification
Robert Fitzpatrick: But unlike other domains that we transport for, I do not see the NOQUEUE reject log entries for this user address, I do see the deliveries for If you don't save the probe result, then the result is thrown away. Telepathic computing is not yet commercially available. Thanks, yes, I understand why it is doing AV. What I don't understand is how come another message to the same recipient around the same time gets delivered to localhost for scanning. Your configuration throws away negative probe results. Therefore, negative probe results never block mail. That is the part I didn't understand. What exactly triggers the other rejections I see with NOQUEUE? I thought each message would be rejected What other rejections? You have shown nothing. Wietse
Re: Understanding address verification
On 2012-02-24 4:33 PM, Wietse Venema wie...@porcupine.org wrote: That is explained in my two sentences above. I am not a pervert who has a better explanation but refuses to share it. Maybe not, but you definitely have one of the driest senses of humor I've ever seen... thanks for making me spill my tea all over my desk... Rotflmao! -- Best regards, Charles
Re: Understanding address verification
On 2/24/2012 4:29 PM, Wietse Venema wrote: That is the part I didn't understand. What exactly triggers the other rejections I see with NOQUEUE? I thought each message would be rejected What other rejections? You have shown nothing. Yes, for I have failed to post all that I have referenced... Feb 24 16:04:29 mx1 postfix/smtpd[48318]: NOQUEUE: reject: RCPT from modadona.com[27.50.112.91]: 450 4.1.1 v...@example2.com: Recipient address rejected: unverified address: Address verification in progress; from=n...@batelco.com.bh to=v...@example2.com proto=ESMTP helo=modadona.com But I think I understand now, thanks for helping, excuse me for trying to completely understand your great works :)
