Re: Understanding postscreen timeouts
On 05/02/2014 03:15 AM, Alex wrote: Hi, On Thu, May 1, 2014 at 5:38 PM, Wietse Venema wie...@porcupine.org mailto:wie...@porcupine.org wrote: Alex: I'm using postfix-2.10.3 with fedora20 and have configured postscreen with spamhaus, barracuda, and a few other DNSBLs. I'm however occasionally receiving the following timeout message: May 1 17:15:01 mail01 postfix/postscreen[4429]: warning: dnsblog reply timeout 10s for swl.spamhaus.org http://swl.spamhaus.org This time limit has unfortunately escaped my attention. It is not yet configurable. The warning message means that postscreen gives up waiting for the DNS lookup result. This is a safety mechanism. I'm also using a half-dozen RBLs, but they don't all always timeout. I see occasional timeouts on residential and co-located servers. By default the resolver *system library* routines wait 5s before retrying; this may be configurable in resolv.conf, but the postscreen time limit is still hard-coded. These are both corporate 10mbs dedicated links and I don't think latency and/or bandwidth is a problem. It actually appears swl.spamhaus.org http://swl.spamhaus.org is the main problem. It doesn't even resolve when I try to do it manually. This was a recommendation I used from this list some time ago. Has something changed? As a feed user of spamhaus, it's easy to see the amount of data that is actually in the zones. Both DWL and SWL zones are empty, so the whitelist experiments of spamhaus seem to be either 'on hold' or dead. Feel free to drop the zones from your setup. This won't fix dns lookup problems in general though. Tom signature.asc Description: OpenPGP digital signature
Re: Understanding postscreen timeouts
Stan Hoeppner: swl.spamhaus.org*-4 list.dnswl.org=127.[0..255].[0..255].0*-2 list.dnswl.org=127.[0..255].[0..255].1*-3 list.dnswl.org=127.[0..255].[0..255].[2..255]*-4 Consolidate these last 3 to something like: list.dnswl.org=127.0.[2..14].[2..3]*-4 These three will result in one list.dnswl.org query, just like the consolidated one. There is no performance difference. However, there is a correctness difference. The consolidated form has the same weight 4 for all results, while the original form has different weights. Wietse
postscreen_dnsbl_timeout parameter (was: Understanding postscreen timeouts)
Wietse Venema: Alex: I'm using postfix-2.10.3 with fedora20 and have configured postscreen with spamhaus, barracuda, and a few other DNSBLs. I'm however occasionally receiving the following timeout message: May 1 17:15:01 mail01 postfix/postscreen[4429]: warning: dnsblog reply timeout 10s for swl.spamhaus.org This time limit has unfortunately escaped my attention. It is not yet configurable. Fixed in Postfix 2.12. Wietse 20140501 Cleanup: postcreen_dnsbl_timeout parameter. Files: mantools/postlink, proto/postconf.proto, global/mail_params.h, postscreen/postscreen.c, postscreen/postscreen_dnsbl.c.
rewrite envelope-sender but *not* from address
I'm working on a generic postfix configuration for servers. I want messages to have a From: address of user@server fqdn, but an envelope-sender/bounce address that's different. in main.cf: canonical_maps=hash:/etc/postfix/canonical canonical_classes = envelope_sender in canonical: @server fqdn some other address Messages sent from this server have the right envelope-sender (rewritten), but the header From: is also rewritten (as if canonical_classes is being ignored). What am I missing? Is there a different way I should be doing this?
Re: rewrite envelope-sender but *not* from address
Jonathan Engbrecht: I'm working on a generic postfix configuration for servers. I want messages to have a From: address of user@server fqdn, but an envelope-sender/bounce address that's different. Please describe your problem, instead of your solution. Wietse
Re: Understanding postscreen timeouts
On 5/2/2014 6:07 AM, Wietse Venema wrote: Stan Hoeppner: swl.spamhaus.org*-4 list.dnswl.org=127.[0..255].[0..255].0*-2 list.dnswl.org=127.[0..255].[0..255].1*-3 list.dnswl.org=127.[0..255].[0..255].[2..255]*-4 Consolidate these last 3 to something like: list.dnswl.org=127.0.[2..14].[2..3]*-4 These three will result in one list.dnswl.org query, just like the consolidated one. There is no performance difference. Correct. The reason for consolidating these is not to reduce queries. However, there is a correctness difference. The consolidated form has the same weight 4 for all results, while the original form has different weights. The consolidated form gives no score to a 4th octet value of [0..1], but gives -4 to [2..3]. This is the key difference. Alex' form and weights are not correct. And that is why I posted the link to the return codes. The second 'octet' is always zero, not a range. The 3rd octet has a range of 2-15, and the 4th octet a range of 0-3. Specifying a range of 0-255 or 2-255 to cover the future may have the opposite effect, resulting in potential disaster, depending on how/if/when dnswl changes things. Such wildcards should not be used. A value of 15 in the 3rd octet means the sender is an Email Marketing Provider. Most people would never whitelist such senders. Alex currently does. Most people would give no preference to a 4th octet score of 0 which means no trust. Alex is giving -2. And he is giving -3 to a 4th octet score of 1, low trust. The recommended scale is -0.1, -1.0, -10, -100, and this is how SpamAssassin handles dnswl scoring. Using a 4 point scale instead of 100, a 4th octet value of 0 or 1 should be given NO whitelisting preference at all, which is what my consolidated example does. Cheers, Stan
lost connection with ]server] while receiving the initial server greeting
I recently moved out mail operations to a new server. The old server is running Postfix 2.8 and the new server 2.10. We had some initial problems with some private blacklists and the new IP but those were resolved. However, I had a curious problem sending mail to icloud.com addresses. Postfix was reporting: lost connection with mx5.icloud.com.akadns.net[17.172.34.68] while receiving the initial server greeting to all MX servers for adadns.net. To get around this initial problem I began relaying outbound mail thru the old server until the blacklisting was all resolved. However, I am still unable to send to the adadns.net servers, still getting dropped connections. They were no help at all resolving the issue. Finally I tried to send an email by telnet to port 25 at the above IP from the new server and sure enough the email went through without issue. I've looked through the release notes for 2.9 and 2.10 and didn't see anything related concerning configuration that might explain this. Any ideas of what I can try next? postconf -n (irrelevant lines removed/edited): broken_sasl_auth_clients = yes command_directory = /usr/local/sbin config_directory = /usr/local/etc/postfix daemon_directory = /usr/local/libexec/postfix data_directory = /var/db/postfix inet_interfaces = all local_transport = virtual mail_owner = postfix mailq_path = /usr/local/bin/mailq manpage_directory = /usr/local/man master_service_disable = message_size_limit = 5000 mydestination = $myhostname, localhost.$mydomain, localhost myhostname = xxx.xxx.xxx myorigin = $myhostname newaliases_path = /usr/local/bin/newaliases queue_directory = /var/spool/postfix readme_directory = no sample_directory = /usr/local/etc/postfix sendmail_path = /usr/local/sbin/sendmail setgid_group = maildrop smtp_tls_note_starttls_offer = yes smtp_use_tls = yes smtpd_delay_reject = yes smtpd_helo_required = yes smtpd_helo_restrictions = permit_mynetworks, reject_non_fqdn_hostname, reject_invalid_hostname, permit smtpd_recipient_restrictions = check_recipient_access hash:/usr/local/etc/postfix/reject_recipients, reject_unauth_pipelining, reject_non_fqdn_recipient, reject_unknown_recipient_domain, check_recipient_maps, permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, permit smtpd_sasl_auth_enable = yes smtpd_sasl_local_domain = smtpd_sasl_path = smtpd smtpd_sasl_security_options = noanonymous smtpd_sender_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_non_fqdn_sender, reject_unknown_sender_domain, permit smtpd_tls_cert_file = /usr/local/etc/postfix/ssl/x.pem smtpd_tls_key_file = $smtpd_tls_cert_file smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes smtpd_tls_session_cache_timeout = 3600s smtpd_use_tls = yes tcp_windowsize = 1400 tls_random_source = dev:/dev/urandom unknown_local_recipient_reject_code = 550
Re: lost connection with ]server] while receiving the initial server greeting
post...@nisny.com: I recently moved out mail operations to a new server. The old server is running Postfix 2.8 and the new server 2.10. We had some initial problems with some private blacklists and the new IP but those were resolved. However, I had a curious problem sending mail to icloud.com addresses. Postfix was reporting: lost connection with mx5.icloud.com.akadns.net[17.172.34.68] while receiving the initial server greeting to all MX servers for adadns.net. What is your servers's public IP address? I suspect that PTR or A lookups are taking too long when the remote SMTP server is trying to determine your server's hostname. Wietse
Re: Understanding postscreen timeouts
Hi, On Fri, May 2, 2014 at 6:45 PM, Stan Hoeppner s...@hardwarefreak.comwrote: On 5/2/2014 6:07 AM, Wietse Venema wrote: Stan Hoeppner: swl.spamhaus.org*-4 list.dnswl.org=127.[0..255].[0..255].0*-2 list.dnswl.org=127.[0..255].[0..255].1*-3 list.dnswl.org=127.[0..255].[0..255].[2..255]*-4 Consolidate these last 3 to something like: list.dnswl.org=127.0.[2..14].[2..3]*-4 These three will result in one list.dnswl.org query, just like the consolidated one. There is no performance difference. Correct. The reason for consolidating these is not to reduce queries. However, there is a correctness difference. The consolidated form has the same weight 4 for all results, while the original form has different weights. The consolidated form gives no score to a 4th octet value of [0..1], but gives -4 to [2..3]. This is the key difference. Alex' form and weights are not correct. And that is why I posted the link to the return codes. The second 'octet' is always zero, not a range. The 3rd octet has a range of 2-15, and the 4th octet a range of 0-3. Specifying a range of 0-255 or 2-255 to cover the future may have the opposite effect, resulting in potential disaster, depending on how/if/when dnswl changes things. Such wildcards should not be used. A value of 15 in the 3rd octet means the sender is an Email Marketing Provider. Most people would never whitelist such senders. Alex currently does. Most people would give no preference to a 4th octet score of 0 which means no trust. Alex is giving -2. And he is giving -3 to a 4th octet score of 1, low trust. The recommended scale is -0.1, -1.0, -10, -100, and this is how SpamAssassin handles dnswl scoring. Using a 4 point scale instead of 100, a 4th octet value of 0 or 1 should be given NO whitelisting preference at all, which is what my consolidated example does. Somehow your first message to the list on this topic didn't make it to me. Had to read it in the archives. Anyway, thanks so much. My postscreen config was generated through a discussion on this list with rob0 some time ago, as well as his postscreen config ( http://rob0.nodns4.us/howto/postfix/main.cf). Perhaps if he's reading, he can correct this. I can't believe I've been whitelisting mass mailers. That's far from what I would want to be doing. In fact, I'm considering figuring out some spamassassin rules to better identify them based on the dnswl queries. Regarding your DNS caching comments, thanks for this too. I hadn't realized there would be bandwidth savings by having one or two DNS servers that are queried on the network versus having a local cache on each mail server. I've always been a bind loyalist, but will consider the powerDNS program if it doesn't improve. I've already made the postscreen changes on the systems, and already noticing fewer DNS queries. I've also removed swl.spamhaus.org entirely, thanks to a conversation with spamhaus and comments from Tom Hendrikx about it being discontinued. Thanks everyone! Alex
Re: lost connection with ]server] while receiving the initial server greeting
On , wie...@porcupine.org wrote: post...@nisny.com: I recently moved out mail operations to a new server. The old server is running Postfix 2.8 and the new server 2.10. We had some initial problems with some private blacklists and the new IP but those were resolved. However, I had a curious problem sending mail to icloud.com addresses. Postfix was reporting: lost connection with mx5.icloud.com.akadns.net[17.172.34.68] while receiving the initial server greeting to all MX servers for adadns.net. What is your servers's public IP address? I suspect that PTR or A lookups are taking too long when the remote SMTP server is trying to determine your server's hostname. Wietse 209.170.151.3 It doesn't seem to be taking long (from 3rd party location 191 msec) and wouldn't that have affected as well dong a telnet?
Re: lost connection with ]server] while receiving the initial server greeting
post...@nisny.com: On , wie...@porcupine.org wrote: post...@nisny.com: I recently moved out mail operations to a new server. The old server is running Postfix 2.8 and the new server 2.10. We had some initial problems with some private blacklists and the new IP but those were resolved. However, I had a curious problem sending mail to icloud.com addresses. Postfix was reporting: lost connection with mx5.icloud.com.akadns.net[17.172.34.68] while receiving the initial server greeting to all MX servers for adadns.net. What is your servers's public IP address? I suspect that PTR or A lookups are taking too long when the remote SMTP server is trying to determine your server's hostname. Wietse 209.170.151.3 It doesn't seem to be taking long (from 3rd party location 191 msec) and wouldn't that have affected as well dong a telnet? You haven't said if this is a persistent problem. One telnet may work now, but that does not exclude the possibility of an eralier problem. What does Postfix log with delay=a/b/c/d when a connection is lost? Are you going through a stateful firewall/NAT that drops sessions to soon? I can speculate until the cows come home, but I prefer not to. Wietse
Re: lost connection with ]server] while receiving the initial server greeting
On , wie...@porcupine.org wrote: post...@nisny.com: On , wie...@porcupine.org wrote: post...@nisny.com: I recently moved out mail operations to a new server. The old server is running Postfix 2.8 and the new server 2.10. We had some initial problems with some private blacklists and the new IP but those were resolved. However, I had a curious problem sending mail to icloud.com addresses. Postfix was reporting: lost connection with mx5.icloud.com.akadns.net[17.172.34.68] while receiving the initial server greeting to all MX servers for adadns.net. What is your servers's public IP address? I suspect that PTR or A lookups are taking too long when the remote SMTP server is trying to determine your server's hostname. Wietse 209.170.151.3 It doesn't seem to be taking long (from 3rd party location 191 msec) and wouldn't that have affected as well dong a telnet? You haven't said if this is a persistent problem. One telnet may work now, but that does not exclude the possibility of an eralier problem. What does Postfix log with delay=a/b/c/d when a connection is lost? Are you going through a stateful firewall/NAT that drops sessions to soon? I can speculate until the cows come home, but I prefer not to. Wietse Sorry, I'm not trying to be difficult but I don't know what your speculation might run and therefore what questions you'll have. There is NO NAT or firewall. relay=mx4.icloud.com.akadns.net[17.172.34.67]:25, delay=177, delays=0.3/0.01/177/ 0, dsn=4.4.2, status=deferred (lost connection with mx4.icloud.com.akadns.net[17.172.34.67] while receiving the initial server greeting)
Re: Understanding postscreen timeouts
On Fri, May 02, 2014 at 08:10:18PM -0400, Alex wrote: On Fri, May 2, 2014 at 6:45 PM, Stan Hoeppner s...@hardwarefreak.comwrote: On 5/2/2014 6:07 AM, Wietse Venema wrote: Stan Hoeppner: swl.spamhaus.org*-4 list.dnswl.org=127.[0..255].[0..255].0*-2 list.dnswl.org=127.[0..255].[0..255].1*-3 list.dnswl.org=127.[0..255].[0..255].[2..255]*-4 Consolidate these last 3 to something like: list.dnswl.org=127.0.[2..14].[2..3]*-4 These three will result in one list.dnswl.org query, just like the consolidated one. There is no performance difference. Correct. The reason for consolidating these is not to reduce queries. However, there is a correctness difference. The consolidated form has the same weight 4 for all results, while the original form has different weights. The consolidated form gives no score to a 4th octet value of [0..1], but gives -4 to [2..3]. This is the key difference. Alex' form and weights are not correct. And that is why I posted the link to the return codes. The second 'octet' is always zero, not a range. The 3rd octet has a range of 2-15, and the 4th octet a range of 0-3. Specifying a range of 0-255 or 2-255 to cover the future may have the opposite effect, resulting in potential disaster, depending on how/if/when dnswl changes things. Such wildcards should not be used. Good point. I thought of this, but did not bother to implement it that way. Eventually I will change it. A value of 15 in the 3rd octet means the sender is an Email Marketing Provider. Most people would never whitelist such senders. Alex currently does. Most people would give no preference to a 4th octet score of 0 which means no trust. Well, I whitelist mildly. Do note that this is a whitelist, under management by people who, I suppose, don't like spam any more than you nor I. A DNSWL.org return of 127.0.15.0 means an email marketer who is nominally trying to limit spam (thus deserving a whitelist entry), but who might be doing that well. A -1 score makes sense. It's not enough to override Zen nor a grouping of other DNSBLs, but if that's the only result from postscreen_dnsbl_sites, it's enough to bypass the after-220 checks. Alex is giving -2. And he is giving -3 to a 4th octet score of 1, low trust. The recommended scale is -0.1, -1.0, -10, -100, and this is how SpamAssassin handles dnswl scoring. Yes, I think -1, -2 and -4 make sense. I lump 4th octet 2 and 3 together because I'm a 2. :) Also, a -4 is going to override any borderline DNSBL score. If it doesn't, I expect something to give somewhere. In my studies, I found very little overlap between the DNSBLs and the DNSWLs. Using a 4 point scale instead of 100, a 4th octet value of 0 or 1 should be given NO whitelisting preference at all, which is what my consolidated example does. But I don't agree with that. Scoring at the content scanning stage differs from scoring in postscreen. DNSWL.org assumes that their trust level none sites are not actually making money from spam. I can't speak for Mathias, but I am pretty sure that he would delist ANY known spammer. Somehow your first message to the list on this topic didn't make it to me. Had to read it in the archives. Anyway, thanks so much. My postscreen config was generated through a discussion on this list with rob0 some time ago, as well as his postscreen config ( http://rob0.nodns4.us/howto/postfix/main.cf). Perhaps if he's reading, he can correct this. Hiya! Yes, I remember. BTW, the better link to share is the HTML page, http://rob0.nodns4.us/postscreen.html , which has all the explanations and warnings. I can't believe I've been whitelisting mass mailers. That's far from what I would want to be doing. In fact, I'm considering figuring out some spamassassin rules to better identify them based on the dnswl queries. If you want to be adventurous (and to violate the DNSWL.org spirit) nothing stops you from using 127.0.15.0 with a positive score in postscreen ... or even as a reject_rbl_client in smtpd! I figure these are at worst the gray hats. And why bother giving delays with the after-220 tests they will pass anyway? So yes, my policy here was considered and deliberate. But looking back, I'll agree that a -1 would make more sense than -2. Stan probably tends to be more aggressive than I am. There's no right/wrong to that, it's a choice. Regarding your DNS caching comments, thanks for this too. I hadn't realized there would be bandwidth savings by having one or two DNS servers that are queried on the network versus having a local cache on each mail server. I've always been a bind loyalist, but will consider the powerDNS program if it doesn't improve. I've always been a BIND loyalist too. Now I'm paid to be a BIND loyalist. I have nothing against the competition, certainly I can't say anything bad
Re: rewrite envelope-sender but *not* from address
On Fri, May 02, 2014 at 05:26:02PM -0400, Jonathan Engbrecht wrote: postfix 2.3.3 Note that Viktor's suggestion of multiple instances assumes a slightly less ancient Postfix version; postmulti(1) began with Postfix 2.6. Time to upgrade? -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: rewrite envelope-sender but *not* from address
On Fri, May 02, 2014 at 10:15:45PM -0500, /dev/rob0 wrote: On Fri, May 02, 2014 at 05:26:02PM -0400, Jonathan Engbrecht wrote: postfix 2.3.3 Note that Viktor's suggestion of multiple instances assumes a slightly less ancient Postfix version; postmulti(1) began with Postfix 2.6. Time to upgrade? I was not suggesting multiple instances, merely the rewriting methodology of the nullclient configuration described in the document. This said Postfix 2.3 is rather old, and if the OP gets a chance, running something more recent (2.9 or later) is not a bad idea. -- Viktor.
Re: Problem with configuring postfix to send a Successful Mail Delivery Report.
Thanks On Wed, Apr 30, 2014 at 1:12 PM, Wietse Venema wie...@porcupine.org wrote: johan van der merwe: Success notifications are requested by the email sender. They ARE NOT automatically sent for all email. What option did you as the email sender specify on the command line? I didn't specified any thing. Whan RCPT TO parameter did you as the email sender specify in the SMTP mail transaction? I was thinking its works like undelivery message in the bounce file. Don't assume, RTFM. http://www.postfix.org/DSN_README.html Wietse
