Re: message_size_limit causes postfix to stop delivering messages
There are no log entries other than normal entries reflecting that the messages have been accepted for delivery, though per another posters' recommendation; I will enable debug logging and give it another look. Please don't. Also, the content filter doesn't announce a SIZE: $ telnet localhost 10025 Trying ::1... Connected to localhost. Escape character is '^]'. 220 mppd You forgot to issue the EHLO command - only after this command the filter might announce the SIZE extension. Or rather LHLO (since mppscan seems to speak lmtp): mppscan unix- - n - 50 lmtp -o lmtp_send_xforward_command=yes -o lmtp_cache_connection=no content_filter = mppscan:[127.0.0.1]:10025 It's a very odd setup, since only locally submitted mail (sendmail command) gets filtered. Mail coming in via smtp is explicitly not sent to the filter: smtpinetn - n - 200 smtpd -o content_filter= submission inet n - n - 200 smtpd -o content_filter= smtps inet n - n - 200 smtpd -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o milter_macro_daemon_name=ORIGINATING -o content_filter= in all three cases we see content_filter= - disabled. Some of these are down: smtpd_client_restrictions = permit_mynetworks, reject_rbl_client bl.spamcop.net, reject_rbl_client sbl-xbl.spamhaus.org, reject_rbl_client cbl.abuseat.org, reject_rbl_client zombie.dnsbl.sorbs.net, reject_rbl_client http.dnsbl.sorbs.net, reject_rbl_client misc.dnsbl.sorbs.net, reject_rbl_client socks.dnsbl.sorbs.net, reject_rbl_client web.dnsbl.sorbs.net, reject_rbl_client ddnsbl.internetdefensesystems.com, reject_rbl_client multi.surbl.org, reject_rbl_client noptr.spamrats.com, permit_sasl_authenticated, reject_rbl_client dyna.spamrats.com, reject_rbl_client pbl.spamhaus.org, reject_rbl_client dul.dnsbl.sorbs.net, check_policy_service inet:127.0.0.1:9998 message_size_limit = 209715200 That's 200MB. -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebra...@charite.de | http://www.charite.de
Re: message_size_limit causes postfix to stop delivering messages
Tomas Macek: Postfix logs all attempts to deliver mail, whether or not successful. Please do not turn on debug logging, it will just make the problem harder to diagnose. You probably have a bug in the VDA patch that breaks when the message size limit exceeds the mailbox size limit. Their code does not handle that correctly. What should be a proper behaviour in this case? The patch should not allow message size limit mailbox size limit. Unpatched Postfix forbids this, but they removed that check. This breaks, among others, mail submitted with sendmail -t, and mail that has recipients added with the Milter protocol. Postfix can't mark the recipient as done. I have added a safety check for that that will abort the program when this sanity check fails. But it does not help when people can't read logfiles. Wietse
reject unknown helo hostname
Just wanted to get public opinion on this one. reject_unknown_helo_hostname My understanding is that to be RFC compliant your HELO greeting must be a valid hostname (ie there is a public A record). However since implementing this restriction under smtpd_helo_restrictions I have had nothing but complaints from people who think their messages are being unfairly blocked. I know we don't live in a perfect world and not everybody is going to have a correctly configured mail server but I don't think it is unreasonable for me to stick to my guns and reject these messages. Having said that, some people have more influence than others and should they voice any concerns I would be forced to make some changes. With that in mind, what would be the best way to make exceptions? My current line of thought is to use a check_helo_access map to make exceptions on a per server basis, is there a better way? Kind regards, James Day (IT Engineer)
Re: reject unknown helo hostname
On Mon, Feb 06, 2012 at 01:36:09PM +, James Day wrote: reject_unknown_helo_hostname Not safe for most use. My understanding is that to be RFC compliant your HELO greeting must be a valid hostname (ie there is a public A record). Right. However since implementing this restriction under smtpd_helo_restrictions I have had nothing but complaints from people who think their messages are being unfairly blocked. I know we don't live in a perfect world and not everybody is going to have a correctly configured mail server but I don't think it is unreasonable for me to stick to my guns and reject these messages. Depends on your site's needs. Good luck! Having said that, some people have more influence than others and should they voice any concerns I would be forced to make some changes. With that in mind, what would be the best way to make exceptions? Precede it with a check_client_access lookup which lists your whitelisted (influential, yet misconfigured) hosts. My current line of thought is to use a check_helo_access map to make exceptions on a per server basis, is there a better way? That would be one of the worst choices, because a forged HELO cannot easily be tested. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: reject unknown helo hostname
On 2/6/2012 7:36 AM, James Day wrote: Just wanted to get public opinion on this one. reject_unknown_helo_hostname I don't use that restriction because there seem to be too many legit hosts that fail, and not enough bad ones that do. Don't forget you can use a restriction with warn_if_reject to get an idea of what it does for a while before you go live with it. Ultimately, anti-spam controls are quite site-specific. Listen to advice, then do what works best for you. -- Noel Jones
RE: reject unknown helo hostname
-Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Noel Jones Sent: 06 February 2012 14:19 To: postfix-users@postfix.org Subject: Re: reject unknown helo hostname On 2/6/2012 7:36 AM, James Day wrote: Just wanted to get public opinion on this one. reject_unknown_helo_hostname I don't use that restriction because there seem to be too many legit hosts that fail, and not enough bad ones that do. Don't forget you can use a restriction with warn_if_reject to get an idea of what it does for a while before you go live with it. Ultimately, anti-spam controls are quite site-specific. Listen to advice, then do what works best for you. -- Noel Jones Rob, Noel, Thanks for your insight, as ever your advice is greatly appreciated. Kind regards, James Day (IT Engineer)
Postfix legacy release 2.7.8, 2.6.14 and 2.5.17
[An on-line version of this announcement will be available at http://www.postfix.org/announcements/postfix-2.7.8.html] Postfix legacy releases 2.7.8, 2.6.14 and 2.5.17 are available. This is the final update for Postfix 2.5, released in 2008. From now on, the supported stable and legacy releases are Postfix 2.6 .. 2.9. New features appear in the Postfix 2.10 development release. * (Postfix 2.5, 2.6) While the Postfix SMTP client's protocol parser uses the last SMTP reply line as intended, the error processing routine was taking information from the beginning of the response. This was causing Protocol error bounces with postscreen multi-line responses and Postfix = 2.6 clients. * (Postfix 2.5, 2.6, 2.7) The fix for local delivery agent database lookup errors was incomplete. The fix correctly added new code to detect database lookup errors with mailbox_transport_maps, mailbox_command_maps or fallback_transport_maps, but it failed to log the problem, and to produce a defer logfile record which is needed for delayed mail and mail too old delivery status notifications. * (Postfix 2.5, 2.6, 2.7) The trace(8) service, used for DSN SUCCESS notifications, did not distinguish between notifications for a non-bounce or a bounce message, causing it to reply to mail with the null sender address. Problem reported by Sabahattin Gucukoglu. * (Postfix 2.5, 2.6, 2.7) The change header milter request could replace the wrong header. A long header name could match a shorter one, because a length check was done on the wrong string. Reported by Vladimir Vassiliev. * (Postfix 2.7) Support for Dovecot auth over TCP sockets, using code that already existed for testing purposes. You can find the updated Postfix source code at the mirrors listed at http://www.postfix.org/. Wietse
Re: reject unknown helo hostname
Hi, James. I use this here, but mine is a small server. When I see what looks like a real message that was blocked, I usually email the postmaster of the other system with a canned letter advising them of the issue and how to fix it. It's usually just a line in their config that sets the helo name. Sometimes I hear back and they're grateful for the pointer, sometimes I never hear back. Other larger sites will silently drop mails from such misconfigured systems, though this isn't consistent. If more systems would enforce this, I think it would be better for everyone involved. Jim On Feb 6, 2012, at 7:36 AM, James Day wrote: Just wanted to get public opinion on this one. reject_unknown _helo_hostname My understanding is that to be RFC compliant your HELO greeting must be a valid hostname (ie there is a public A record). However since implementing this restriction under smtpd_helo_restrictions I have had nothing but complaints from people who think their messages are being unfairly blocked. I know we don’t live in a perfect world and not everybody is going to have a correctly configured mail server but I don’t think it is unreasonable for me to stick to my guns and reject these messages. Having said that, some people have more influence than others and should they voice any concerns I would be forced to make some changes. With that in mind, what would be the best way to make exceptions? My current line of thought is to use a check_helo_access map to make exceptions on a per server basis, is there a better way? Kind regards, James Day (IT Engineer)
Re: message_size_limit causes postfix to stop delivering messages
On 2/6/2012 6:01 AM, Wietse Venema wrote: Tomas Macek: You probably have a bug in the VDA patch that breaks when the message size limit exceeds the mailbox size limit. Their code does not handle that correctly. That seems highly plausible. What should be a proper behaviour in this case? The patch should not allow message size limit mailbox size limit. Unpatched Postfix forbids this, but they removed that check. In this case, mailbox_size_limit shouldn't come in to play. If I'm reading http://www.postfix.org/postconf.5.html#mailbox_size_limit correctly, that parameter only effects local delivery; not virtual. - Nick Bright smime.p7s Description: S/MIME Cryptographic Signature
Re: message_size_limit causes postfix to stop delivering messages
Nick Bright: The patch should not allow message size limit mailbox size limit. Unpatched Postfix forbids this, but they removed that check. In this case, mailbox_size_limit shouldn't come in to play. If I'm reading http://www.postfix.org/postconf.5.html#mailbox_size_limit correctly, that parameter only effects local delivery; not virtual. I should have written: virtual_mailbox_limit. I suggest that you look for Postfix panic, fatal, error or warning messages as per these instructions: http://www.postfix.org/DEBUG_README.html#logging LOOK FOR OBVIOUS SIGNS OF TROUBLE = Postfix logs all failed and successful deliveries to a logfile. The file is usually called /var/log/maillog or /var/log/mail; the exact pathname is defined in the /etc/syslog.conf file. When Postfix does not receive or deliver mail, the first order of business is to look for errors that prevent Postfix from working properly: % egrep '(warning|error|fatal|panic):' /some/log/file | more Note: the most important message is near the BEGINNING of the output. Error messages that come later are less useful. The nature of each problem is indicated as follows: * panic indicates a problem in the software itself that only a programmer can fix. Postfix cannot proceed until this is fixed. * fatal is the result of missing files, incorrect permissions, incorrect configuration file settings that you can fix. Postfix cannot proceed until this is fixed. * error reports an error condition. For safety reasons, a Postfix process will terminate when more than 13 of these happen. * warning indicates a non-fatal error. These are problems that you may not be able to fix (such as a broken DNS server elsewhere on the network) but may also indicate local configuration errors that could become a problem later. When no mail is delivered, the logfile will tell you why. Wietse
Re: message_size_limit causes postfix to stop delivering messages
On 2/6/2012 2:19 AM, Ralf Hildebrandt wrote: Also, the content filter doesn't announce a SIZE: You forgot to issue the EHLO command - only after this command the filter might announce the SIZE extension. Or rather LHLO (since mppscan seems to speak lmtp): Oops! $ telnet localhost 10025 Trying ::1... Connected to localhost. Escape character is '^]'. 220 mppd LHLO TEST 250-mppd 250-PIPELINING 250-8BITMIME 250 XFORWARD NAME ADDR PROTO HELO SOURCE quit 221 Service closing transmission channel content_filter = mppscan:[127.0.0.1]:10025 It's a very odd setup, since only locally submitted mail (sendmail command) gets filtered. Mail coming in via smtp is explicitly not sent to the filter: smtpinetn - n - 200 smtpd -o content_filter= submission inet n - n - 200 smtpd -o content_filter= smtps inet n - n - 200 smtpd -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o milter_macro_daemon_name=ORIGINATING -o content_filter= in all three cases we see content_filter= - disabled. I haven't found any example of mail that doesn't flow through the content filter. This is how the vendors' setup scripts configure postfix to interact with the daemon (it's a commercial product). When I asked my vendor if the -o content_filter= should be removed, the vendor replied: No, this is because we actually have the policy server which is first, then it is passing the message to the content_filter defined in main.cf; so if you remove that line from master.cf all mail will be scanned twice. Some of these are down: RBL list snipped Unrelated to the issue at hand. message_size_limit = 209715200 That's 200MB. Yes, I know; however the actual value isn't relevant - even when I explicitly set the value of message_size_limit to the default value the same non-delivery queuing behavior occurs. I sincerely doubt that the content_filter configuration is related to the actual problem. - Nick Bright smime.p7s Description: S/MIME Cryptographic Signature
Re: message_size_limit causes postfix to stop delivering messages
On 2/6/2012 2:17 PM, Wietse Venema wrote: Nick Bright: The patch should not allow message size limit mailbox size limit. Unpatched Postfix forbids this, but they removed that check. I should have written: virtual_mailbox_limit. virtual_mailbox_limit isn't defined; but I am using a virtual_mailbox_limit_maps to retrieve quotas from LDAP. However, all of my quotas are at least 5x the size of the message_size_limit I've specified; so even with the check removed that condition isn't happening. I suggest that you look for Postfix panic, fatal, error or warning messages as per these instructions: http://www.postfix.org/DEBUG_README.html#logging Wietse I will look in to that tonight during maintenance hours. Thank you, Nick Bright smime.p7s Description: S/MIME Cryptographic Signature
Transport: Multiple routes to internal domain
I'm using Postfix\Amavis\Spamassassin\Clamav to scan incoming emails for virus and spam and forward to our internal MS Exchange email system. Postifx shares the Internet domain with MS Exchange, each forwarding messages to unknown accounts to the other system. MS Exchange uses clustering to duplicate it's mailbox databases to 2 different servers. How do I setup Postfix to automatically forward messages to one of the MS Exchange servers if the other one goes offline? I currently use an IP number in square brackets in Postfix's transport map to route to one of the MS exchange servers. Thanks, Greg. I'm using Postfix\Amavis\Spamassassin\Clamav to scan incoming emails for virus and spam and forward to our internal MS Exchange email system.Postifx shares the Internet domain with MS Exchange, each forwarding messages to unknown accounts to the other system.MS Exchange uses clustering to duplicate it's mailbox databases to 2 different servers. How do I setup Postfix to automatically forward messages to one of the MS Exchange servers if the other one goes offline?I currently use an IP number in square brackets in Postfix's transport map to route to one of the MS exchange servers.Thanks,Greg.
Re: Transport: Multiple routes to internal domain
Hi! I would answer you with another question: In the event of a server failure, how are users directed to the other server? I mean, there are several ways of doing that, and knowing your current one would be helpful. Sincerely, Ildefonso Camargo. On Mon, Feb 6, 2012 at 6:57 PM, Greg Wilson gr...@actionforms.com.au wrote: I'm using Postfix\Amavis\Spamassassin\Clamav to scan incoming emails for virus and spam and forward to our internal MS Exchange email system. Postifx shares the Internet domain with MS Exchange, each forwarding messages to unknown accounts to the other system. MS Exchange uses clustering to duplicate it's mailbox databases to 2 different servers. How do I setup Postfix to automatically forward messages to one of the MS Exchange servers if the other one goes offline? I currently use an IP number in square brackets in Postfix's transport map to route to one of the MS exchange servers. Thanks, Greg.
Re: Transport: Multiple routes to internal domain
Greg Wilson: 2 different servers. How do I setup Postfix to automatically forward messages to one of the MS Exchange servers if the other one? goes offline? Two options: A) Assuming that you use the relay transport in master.cf (which you should if relaying mail from outside): /etc/postfix/master.cf: relay unix - - n - - smtp -o smtp_fallback_relay=[1.2.3.4] B) In the transport map, specify a hostname that resolves to TWO IP addresses. Make up your own DNS or /etc/hosts entry if you need to. Wietse
Re: Transport: Multiple routes to internal domain
Thanks for the advice. I don't use relay maps for the domain as the Internet doamin is shared betweent he MS Exchange server and the Postfix server. i.e I use MySql address lookups onthe Postfix server so it's easy to create addresses to forward email to different or multiple accounts. e.g sa...@xxx.com I don't think that multiple DNS records will work. (Although I may be wrong.) I use this technique, DNS round robin to evenly spread rdp connections to our terminal servers. My understanding is that a device does a DNS lookup and the server hands out each different IP address sequentially. Each device uses (caches) the first IP address it recieves until it's rebooted. i.e When the primary MS Exchange server went offline, Postifx wouldn't necessarally do another DNS looup and find the second record. Is it possible to setup multiple transport records wth different costs to a domain? This may be a solution. Cheers, Greg. Greg Wilson: 2 different servers. How do I setup Postfix to automatically forward messages to one of the MS Exchange servers if the other one goes offline? Two options: A) Assuming that you use the relay transport in master.cf (which you should if relaying mail from outside): /etc/postfix/master.cf: relay unix - - n - - smtp -o smtp_fallback_relay=[1.2.3.4] B) In the transport map, specify a hostname that resolves to TWO IP addresses. Make up your own DNS or /etc/hosts entry if you need to. Wietse
Re: reject unknown helo hostname
Den 2012-02-06 14:36, James Day skrev: My current line of thought is to use a check_helo_access map to make exceptions on a per server basis, is there a better way? write to postmas...@senderdomain.example.org perfectly done by users that complain :-)
Re: Transport: Multiple routes to internal domain
I've been testing Postifx for some solutions... One attempt was to make 2 entries with the same host name in /etc/hosts e.g 10.222.100.1 exchange.mydomain.local exchange 10.333.200.2 exchange.mydomain.local exchange Then changed the transport map to mydomain.local smtp:[exchange.mydomain.local] My info is that the square brackets stop Postifix doing mx record lookups. This didn't work and I don't know why. It works fine with an IP address inthe square brackets and the Linux box can resolve exchange.mydoamin.local to an IP. Any suggestions? Thanks for the advice. I don't use relay maps for the domain as the Internet doamin is shared betweent he MS Exchange server and the Postfix server. i.e I use MySql address lookups onthe Postfix server so it's easy to create addresses to forward email to different or multiple accounts. e.g sa...@xxx.com I don't think that multiple DNS records will work. (Although I may be wrong.) I use this technique, DNS round robin to evenly spread rdp connections to our terminal servers. My understanding is that a device does a DNS lookup and the server hands out each different IP address sequentially. Each device uses (caches) the first IP address it recieves until it's rebooted. i.e When the primary MS Exchange server went offline, Postifx wouldn't necessarally do another DNS looup and find the second record. Is it possible to setup multiple transport records wth different costs to a domain? This may be a solution. Cheers, Greg. Greg Wilson: 2 different servers. How do I setup Postfix to automatically forward messages to one of the MS Exchange servers if the other one goes offline? Two options: A) Assuming that you use the relay transport in master.cf (which you should if relaying mail from outside): /etc/postfix/master.cf: relay unix - - n - - smtp -o smtp_fallback_relay=[1.2.3.4] B) In the transport map, specify a hostname that resolves to TWO IP addresses. Make up your own DNS or /etc/hosts entry if you need to. Wietse
Re: Transport: Multiple routes to internal domain
On Tue, Feb 07, 2012 at 11:42:37AM +1100, Greg Wilson wrote: I use this technique, DNS round robin to evenly spread rdp connections to our terminal servers. My understanding is that a device does a DNS lookup and the server hands out each different IP address sequentially. Each device uses (caches) the first IP address it recieves until it's rebooted. That might be true for rdp connections to your terminal servers, but (luckily!) it's a bit more complicated. The DNS server sends a reply containing all the IP addresses. The order varies. If the code asking the question only wants one address, then it takes only one, and the next time it asks the question it might get another answer. Postfix, however, understands that there are multiple addresses and tries them all, one after the other in a random order until one replies or until it has tried them all and decides to wait before trying again. After waiting Postfix will make another DNS lookup. The response to that lookup may be cached since the previous lookup, but the cache is valid only until the record's time to live (TTL) expires. The TTL is set in the DNS server. It can be anything from zero (do not cache) to a week or more. A common default value is 24 hours. Of course, in the case of a long-lived TCP connection you may have the impression that the IP address is used until the device is restarted, and you might even be correct (for an RDP client running on Windows, for example), but that is not the case when sending mails. Is it possible to setup multiple transport records wth different costs to a domain? This may be a solution. You can do unequal load balancing by creating multiple records with the same IP. That could work using /etc/hosts, you'd have to test. You can do priorities (first try X and if it doesn't work try Y then Z) by using different-priority MX records. This needs access to your DNS server, and cannot be done with /etc/hosts. Hope this helps.
