Selective bounce_template_file
Hello, I would like to have different bounce_template_files per domain. Is that possible? Something like, if bounce message is to a domain *.pt use the bounce_template _file bounce.pt.cf. If this file doesn't exists use the default bounce.cf If the bounce message is to a domain *.es use the template bounce.es.cf... What i would like to achieve is to have translated bounce messages per recipient domain. Any other ideas? Thanks, Nuno Fernandes
Re: Graphing mail stats
On 15/2/2013 9:47 μμ, Nikolaos Milas wrote: However, although I have successfully patched both mailgraph.pl and mailgraph.cgi, it doesn't seem to work. (I did it twice to confirm.) In the place of the "Bounced-Virus-... etc" diagram nothing appears except a "mailgraph" word. Only the "Sent-Received" diagram appears properly. Note that the patch proposed at: http://www.networkmonkey.de/mailgraph-und-postscreen/ to support postscreen does work. So, this is what I am using at the moment. If the more complete patch Birta proposes works, then it will be preferable because it should display postscreen activity separately (while now it appears as "spam"). So, if there is some suggestion on how to make it work, I would be interested. Regards, Nick
Re: Trouble configuring backup MX to reject unauth destination
Sat, 09 Feb 2013 10:25:31 -0600 skrev Noel Jones : ... > Nothing wrong with this setup. It's very easy to configure, > requires no third-party software or additional packages, and it's > easy to understand where your mail goes. I expect that's why it's > used as an example on the spamassassin wiki, and doesn't necessarily > mean it's the recommended or preferred method. > > It's not necessarily the highest performance or the most flexible, > but if it suits your needs, no need to change. > > Folks who need more usually pick some third-party filtering software > that can run pre-queue as an smtpd_proxy_filter or milter. These > are, without exception, more complicated than the setup you > currently have. The big advantage of a pre-queue filter is you can > safely REJECT unwanted mail. > > Amavisd-new is a popular choice for pre-queue filtering since it's > fast, reliable, flexible, and can integrate both SpamAssassin and > antivirus. > > > -- Noel Jones Sorry for the late response, it took some time to dig through all the information. The use of pre-queue filtering would solve another problem I've been working on: What to do with mail from (user)blacklisted senders. I plan on upgrading Debians stable Postfix to the current stable version of 2.10 so I may benefit from postscreen, and that will probably be a good time to install amavisd-new as a pre-queue filter. Thank you for the help once again.
Re: Trouble configuring backup MX to reject unauth destination
On Feb 16, 2013, at 12:18, Titanus Eramius wrote: > I plan on upgrading Debians stable Postfix to the current stable > version of 2.10 so I may benefit from postscreen, and that will > probably be a good time to install amavisd-new as a pre-queue filter. > > Thank you for the help once again. A possible shortcut to getting postscreen is using the 2.9.3 version available in the Debian backports repository. That's what we currently use, instead of building custom packages. HTH, Jona
Re: Problem with line which is longer than 256 characters
On 02/11/2013 11:36 PM, Wietse Venema wrote: Rolf E. Sonneveld: In general, Postfix is running fine and this Postfix instance is also running fine. However, there is one SMTP client (of which we are not in control), that sends messages with long lines to this server running Postfix. There is a problem with the communication between this client and the server: whenever the clients sends a message which includes one long line (377 characters, excluding the CRLF), the client seems to 'hang' after character # 256 of this long line is transmitted. Then, after some time the connection times out. A tcpdump recording will reveal if the client stops sending or if the server stops reading (it's revealed by TCP receive window size). Once this is known the search can be focused. It could be somethinh as stupid as poorly-implemented anti-virus software. http://www.postfix.org/DEBUG_README.html#sniffer thanks for your answer. I did a tcpdump for the session but when analysing it, I could not find a clear cause. At the end of the day, it appeared to have been a cli/tty related limitation (of Solaris?). See for a discussion https://forums.oracle.com/forums/thread.jspa?messageID=8292168). When sending the same data using a perl script it worked without a problem. /rolf
Re: Selective bounce_template_file
On Sat, Feb 16, 2013 at 09:51:53AM +, Nuno Fernandes wrote: > I would like to have different bounce_template_files per domain. Is that > possible? Postfix has no support for sender-domain (recipient of bounce domain) specific bounce templates. Nor do domains map very well to the preferred language of the particular sender. The boilerplate text of a bounce largely wastes the readers time before they (if their MUA lets them) see the real reason the message bounced in the per original-recipient error message collected from the text of SMTP (or other delivery mechanism) responses. A bounce template in Spanish or Portuguese will not help the recipient (original sender) understand the delivery error, the actual problem description is typically english text generated by the MTA that rejects the message. Thus in practice the least common denominator for Spanish and Portuguese is English. Make the bounce template as short as possible, it just distracts the reader from the real text they want to read. Perhaps replace: This is the mail system at host $myhostname. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. For further assistance, please send mail to postmaster. If you do so, please include this problem report. You can delete your own text from the attached returned message. The mail system with: Error notice: which is English text that consists entirely of Latin-derived words, that will likely be understood also by Spanish, Portuguese and French readers. Even if someone does not understand "Error notice", they'll be spared having to worry about the offending text, its brevity will cause less concern that they're missing out on something important. Some MUAs, when displaying a bounce, don't show the text at all! They display machine-generated text based on the message/delivery-status (https://tools.ietf.org/html/rfc3464#section-2.1) portion of the bounce. -- Viktor.
Re: Trouble configuring backup MX to reject unauth destination
Sat, 16 Feb 2013 12:39:24 +0100 skrev DTNX Postmaster : > On Feb 16, 2013, at 12:18, Titanus Eramius wrote: > > > I plan on upgrading Debians stable Postfix to the current stable > > version of 2.10 so I may benefit from postscreen, and that will > > probably be a good time to install amavisd-new as a pre-queue > > filter. > > > > Thank you for the help once again. > > A possible shortcut to getting postscreen is using the 2.9.3 version > available in the Debian backports repository. That's what we > currently use, instead of building custom packages. > > HTH, > Jona > Thank you for pointing the obvious out. I don't know why I didn't thought of backports, but I will surely be using 2.9.3 from there instead of building from source.
Re: Problem with line which is longer than 256 characters
Rolf E. Sonneveld: > On 02/11/2013 11:36 PM, Wietse Venema wrote: > > Rolf E. Sonneveld: > >> In general, Postfix is running fine and this Postfix instance is also > >> running fine. However, there is one SMTP client (of which we are not in > >> control), that sends messages with long lines to this server running > >> Postfix. There is a problem with the communication between this client > >> and the server: whenever the clients sends a message which includes one > >> long line (377 characters, excluding the CRLF), the client seems to > >> 'hang' after character # 256 of this long line is transmitted. Then, > >> after some time the connection times out. > > A tcpdump recording will reveal if the client stops sending or if > > the server stops reading (it's revealed by TCP receive window size). > > Once this is known the search can be focused. It could be somethinh > > as stupid as poorly-implemented anti-virus software. > > > > http://www.postfix.org/DEBUG_README.html#sniffer > > thanks for your answer. I did a tcpdump for the session but when > analysing it, I could not find a clear cause. Based on the bits on the wire it is 100% clear whether the client stops sending or whether the receiver stops receiving. Just look at the TCP window. Wietse > At the end of the day, it > appeared to have been a cli/tty related limitation (of Solaris?). See > for a discussion > https://forums.oracle.com/forums/thread.jspa?messageID=8292168). When > sending the same data using a perl script it worked without a problem. > > /rolf > >
