Re: SMTP AUTH for all users except for our mailing-lists ?
On 07/03/2011 02:37 PM, Benny Pedersen wrote: On Sun, 03 Jul 2011 10:14:32 +0200, Frank Bonnet wrote: Hello I would like to force all my real users to use SMTP AUTH ( SASL + LDAP ) but we have many internal mailing lists running and I wonder if it is possible to add an exception for that purpose , I think it would be possible with mynetwork statement but I would not screw up our production server and need experts advices. /etc/postfix/main.cf: smtpd_sasl_exceptions_networks = !192.0.2.171/32, 192.0.2.0/24 http://www.postfix.org/SASL_README.html thank you :-)
Re: strange delay in pre-queue phase
On 01/07/11 19:24, Wietse Venema wrote: The fix is for the client to appendCRLF.CRLF to the message content before writing it to the network. The workaround is for the client to turn off Nagle delays. Thanks. That was it for sure. Just for the benefit of others: - it was hard for me to change the php client library, although I have posted a bug for Swift Mailer http://swiftmailer.lighthouseapp.com/projects/21527-swift-mailer/tickets/204-nagle-delays-affect-mail-sending-throughput - it was also hard to change the client to turn off Nagle delays, because Swift Mailer is using the wrong php library to allow that. So I changed the system wide Nagle behaviour on the server, which is a freebsd system. http://lists.freebsd.org/pipermail/freebsd-stable/2008-June/043325.html sysctl net.inet.tcp.delacktime=10 # (default 100ms) Which reduced 90% of the delay. Not ideal, but fine in this case, since most of the traffic to that hosts is LAN or very high speed WAN. Thanks again. -- Oliver Schonrock
Re: unverified_recipient_tempfail_action = permit
--- In postfix-us...@yahoogroups.com, Wiebe Cazemier wiebe@... wrote: Hi, I don't really know where to post feature ideas, but this seems the only viable option. I was setting up a fallback MX server with Postfix and was struggling with preventing backscatter mail. I thought I found a good solution, but it turned out to be an illegal option. Postfix has the ability to do recipient address verification. When postfix acts as a relay server, this prevents backscatter mail (bounces of messages because the server that is relayed to doesn't accept the user). Backscatter is usually caused by spam of course, because spam is sent to all kinds of users @example.com. I had in mind to use recipient address verification to avoid that and then set unverified_recipient_tempfail_action = permit. The idea behind this was: - Prevent backscatter mail when the primary host is up because every address is verified first. - Accept all mail when the primary host is down, so that incoming messages aren't deferred. But permit is not a valid option for unverified_recipient_tempfail_action. Would it be an idea to implement this? I know I can use permit_mx_backup and permit_mx_backup_networks, but I'd rather not have to maintain a list of networks on the fallback server, partly because I want to be a fallback server for servers that I don't maintain and of which I have no idea if the address changes. Regards, Wiebe I'd like to chime in and add my support to this. Frankly, some of the obtuse replies to this reasonable feature request have been bordering on rude imho. I had a very similar problem to Wiebe last week when our primary mx started crashing because it could no longer communicate with our Dovecot SASL provider (dovecot had killed itself due to the system clock suddenly changing by 86 seconds, which itself was caused by a misconfigured ntp.conf file). While the primary was down, our secondary mx accepted mail for 3 of the domains it is configured to backup but all email to the fourth domain was deferred because it just so happened that the relevant entries in the verify_cache had expired shortly before the primary went down. The outage lasted about 4 hours but it would have been nice if senders hadn't received defferal messages and I could have simply flushed the backup queue to get the mail across once the primary was running again. Instead we had to wait for the affected sender MTAs to re-try delivery. unverified_recipient_tempfail_action = permit would have solved this problem with the small penalty of a brief period of potential backscatter. Where is the down side? Charlie
Re: unverified_recipient_tempfail_action = permit
On Mon, 4 Jul 2011 04:48:44 -0700 (PDT) Charlie Orford articulated: unverified_recipient_tempfail_action = permit would have solved this problem with the small penalty of a brief period of potential backscatter. The potential backscatter is enough to turn me off on the proposal. Now, if you could develop something that did not involve that problem then I think it might be given a warmer welcome by the community. Then again, that is my own 2¢ on the matter. -- Jerry ✌ postfix-u...@seibercom.net _ TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html
Re: unverified_recipient_tempfail_action = permit
On Mon, Jul 04, 2011 at 04:48:44AM -0700, Charlie Orford wrote: unverified_recipient_tempfail_action = permit would have solved this problem with the small penalty of a brief period of potential backscatter. Where is the down side? That small penalty sure is a down side. If I would provide backup service for someone else, I would absolutely insist that the primary must never reject my mail for that domain. Let THEM be the spammer, not me. If you're intent on this, you can implement it yourself with simple scripts. Best would be a small policy service, but a shell script running from crontab would suffice. The cron job would check to see if the primary MX is reachable, and exit if so. A check_recipient_access lookup for the backup domain would return defer or defer_if_permit. If the primary MX is not available, the access map would be changed to return dunno. The cron job continues checking availability of the primary MX, and changes the access map back, and optionally runs postfix flush, when the primary MX comes back. A policy service could do the same thing in real time, without the possible delay of the cron job interval. It could also flag clients as likely spammers when they attempt to deliver to the backup domain while the primary MX is up. References: http://www.postfix.org/SMTPD_ACCESS_README.html http://www.postfix.org/access.5.html http://www.postfix.org/SMTPD_POLICY_README.html -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
Re: Relay hosts + forwarding specific addresses
On Sun, Jul 03, 2011 at 01:44:26AM +0200, Jeroen wrote: On 3 July 2011 01:07, /dev/rob0 r...@gmx.co.uk wrote: f...@bar.com forward to foo...@gmail.com Same-envelope forwarding to external sites is also quite likely to become a source of problems for you. When you receive and forward spam to this address, gmail content filtering will identify it as such, and will regard you as the spammer. I just tried the virtual_alias_maps option, and indeed this works. Like you said, it does not change the envelop. Gmail does in fact accept it, but this might not be the case for other MX's. Is there an option for postfix to change the envelop? Not exactly, but there are workarounds. Delivery to a script which runs sendmail(1) and sets a sender is one such workaround. For more safety, possibly, you could run mutt(1) or Heirloom mailx to MIME- encode the message as an attachment. For absolute safety, mutt can invoke gpg(1) and encrypt the message. Since gmail [so far] is accepting your forwarded mail, it might be good enough to employ aggressive pre-acceptance or pre-forwarding spam controls. If there is any spam sign, quarantine and do not send it on its way. DKIM exists to help with this. Whether or not it would help with the specific problem, there is no way to know. But DKIM signing of outbound mail is a good idea in any case. From reading the documentation, I think I need to implement virtual_maps, Did you note in the documentation that virtual_maps was deprecated with Postfix 2.0? Actually I didn't; I found the manual page while googling. It might have referred to an old version of the manual, or might have got it from another source. I searched and read many pages before consulting the mailing list. With most free software projects, and especially with Postfix, it's a good idea to check the project's own documentation before Google. And when you do come down to the need to Google for Postfix, start with searches of the various online archives of this mailing list. Most packages of Postfix from third-party distributors should include the complete documentation. I recommend to consult the local copy before the online versions, because features are added, and you must read carefully to see if a feature was not available in your version. If installing from source, be sure to set html_directory. If you're going to do much with Postfix, bookmark that in your browser. :) -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
Re: unverified_recipient_tempfail_action = permit
Jerry: On Mon, 4 Jul 2011 04:48:44 -0700 (PDT) Charlie Orford articulated: unverified_recipient_tempfail_action = permit? would have solved this problem with the small penalty of a brief period of potential backscatter. The potential backscatter is enough to turn me off on the proposal. Now, if you could develop something that did not involve that problem then I think it might be given a warmer welcome by the community. Then again, that is my own 2? on the matter. The current state does not have that problem. With unverified_recipient_tempfail_action=defer_if_permit or defer, Postfix will pass mail for recipients that were cached less than 31 days ago. In addition, Postfix attempts to refresh recipients after 7 days so that active recipients never expire. If a recipient is not cached, then a tempfail_action of permit results in backscatter which is not safe. If this is a concern, increase the address_verify_positive_expire_time so that Postfix never expires a recipient. If a recipient never receives email, then it is not a problem if mail is delayed by a few hours. Wietse
Re: unverified_recipient_tempfail_action = permit
Jerry: On Mon, 4 Jul 2011 04:48:44 -0700 (PDT) Charlie Orford articulated: unverified_recipient_tempfail_action = permit? would have solved this problem with the small penalty of a brief period of potential backscatter. The potential backscatter is enough to turn me off on the proposal. Now, if you could develop something that did not involve that problem then I think it might be given a warmer welcome by the community. Then again, that is my own 2? on the matter. My previous reply suffered from damage while editing. This is an attempt to fix it. The problem with recipients not in the verify cache is easily addressed with existing Postfix features. With unverified_recipient_tempfail_action=defer_if_permit or defer, Postfix will pass mail for recipients that were added to the verify cache up to 31 days ago. In addition, Postfix attempts to refresh information after 7 days so that active recipients don't expire. These are the default settings, which you can change. To avoid the expiration of known recipients after 31 days, you can increase the address_verify_positive_expire_time setting to a larger value. If you set the expiration time too long, there will be backscatter after a recipient's account is terminated. Don't set it to years. That leaves the rare case of a recipient who almost never receives email. I think it would not be a problem if such email is delayed by a few hours when the primaty MX host is down. Wietse
Re: SMTP AUTH for all users except for our mailing-lists ?
On 7/3/2011 3:14 AM, Frank Bonnet wrote: Hello I would like to force all my real users to use SMTP AUTH ( SASL + LDAP ) but we have many internal mailing lists running and I wonder if it is possible to add an exception for that purpose , I think it would be possible with mynetwork statement but I would not screw up our production server and need experts advices. This is what the submission (TCP 587) daemon is for. Use it instead of SASL over TCP 25 and all your problems disappear. -- Stan
