Re: Change error messages returned by Postfix
On Monday 03 January 2011 17:35:51 Wietse Venema wrote: > J. Roeleveld: > > On Monday 03 January 2011 04:12:46 Wietse Venema wrote: > > > Mark Scholten: > > > > Hello, > > > > > > > > Should I look in the source or is there a better location to change > > > > the texts returned by Postfix after the error code for a connecting > > > > MTA? I'd like to give custom messages back for (example) a failed > > > > rDNS check or helo check. I don't want to change the returned number > > > > (421 or 550 if I'm correct), just the message to point them to a > > > > page we own to get information about how to fix the error or request > > > > whitelisting for the check. > > > > > > > > Changing the messages in the source isn't something I'd like to do, > > > > but if that is the location to change it I'll change it there. I > > > > didn't find it in the documentation (but I might have overlooked > > > > something). > > > > > > This is not configurable. > > > > > > Wietse > > > > Just out of curiosity, why is this not configurable? > > Postfix source code is "free" for you, but it actually requires > real human effort by maintainers, and making all the reject response > texts configurable would be a major project. I'm not familiar with the source code of postfix, which is why I asked. I think if someone really wants this, he/she would need to do most of the work and convince you and your colleagues to add the patches to the code. > > And would a feature request for this be appreciated? > > Instead of making every response configurable, a more practical > solution is to configure ONE response that gets appended to ALL > the SMTP server's reject messages. Effectively, this turns the > one-line reject into a two-line response, one chosen by Postfix > and one chosen by the system adminstrator. > > This can be done in the SMTP output routine. It also means that > > 421 4.4.2 host.example.com Error: timeout exceeded > > becomes: > > 421-4.4.2 host.example.com Error: timeout exceeded > 421 4.4.2 For assistance, contact the helpdesk at 800-555-0101 > > I wonder how many calls you would actually get for that. I'd put a webpage there instead of a number, but not many people actually get to see those codes. I'm not even sure this full text would appear in the result of "mailq" which is the first place I look when I find my emails are not arriving. > That said, the likelihood that someone will actually pay attention > to the gibberish from SMTP server responses is small. It sounds > like something that keeps lawyers happy. Which is not necessarily a good thing :) -- Joost PS. All the best wishes for 2011 to everyone
Autoresponse problem (Sorry for a bit OT - but somehow Postfix related)
Hi Postfix-Experts, I have the need to activate an autoresponder in my postfix server. From the postfix pages i found the package "autoresponse" very appealing and convinient. Installing and hooking into postfix via postfix pipe command (using exactly the instructions from the autoresponse homepage) went well. Also the admin functions (set an autoresponse, clear an autoresponse, blah, ...) works fine. Autoresponding works fine in MOST cases, but sadly not in all. I have no idea and see no rule why some email addresses work and some not. I digged the problem down and saw (with some traceprints in the autoresponse script) that the incoming mail is forwarded to autoresponse correctly, but somehow in some circumstances the "original_recipient" address is truncated by the TLD part. Meaning, autoresponse script only gets "myn...@mydomain" instead of the correct "myn...@mydomain.de" from postfix. The TLD is missing here. That happens, already said, not with all but some addresses (with no rule at the moment i can see). But it happens always with the same addresses. That means, IF an address gets transferred truncated from postfix to autoresponse script, it will happen EVERY TIME with that address. While an address that works, will work also all the time. I must use "original_recipient" (not "recipient") in master.cf, as i do some rewriting with aliases to match local linux user accounts with external email addresses. E.g. 1. Incoming Mail to myn...@mydomain.de 2. Postfix virtual domains rewrite like: myname j...@m15 (jt is my local unix login and m15 the hostname) 3. Delivery local to ~/users/jt/Maildir/ I want to keep the original destination to see later in my MUA to which address the mail belongs. I can see in the logfile, that postfix first picks up the email with the correct (full) recipient address, then delivers it to autoresponse and clean up. At this point autoresponse already got the truncated version of the email address. Then autoresponse generates a new mail (by sendmail command) to deliver the mail to the local users inbox using the (now truncated) address, after checking if an autoresponse for that address have been set (and also generates a mail back to the sender if so). This also shows up in the logfile (the maybe generated autoresponse mail to sender and the forwarded original message to original_recipient). The problem is now, that with the missing TLD (in case it happens) postfix have no idea where to deliver the generated mail by autoresponse, asks my DNS and gets a "non exist" answer (what is correct, as this domain - without the TLD - does not exist). So postfix reacts as expected and the sender gets an "undeliverable" mail from my mailer-daemon and the mail is not delievered to the recipient. :( I thought i would be smart and do a small workaround. Changing autoresponse script, so that a small Perl script is called from autoresponse bash script that checks for the existence of a valid TLD in the recipient address. That works fine when i test it within a shell. But when i hook that adapted autoresponse script into postfix i get a "can't redirect stream" message in the logfile and postfix goes crazy, stopping delivering anything. :( I need to redirect stdout from my Perl script to autoresponse bash script, to receive the (maybe) changed recipient address (maybe a TLD added) back into my autoresponse script. Now i'm completely out of ideas. So i sadly have to bother you with the following questions: - Does anyone have an idea/hint for me why some addresses loose the TLD part when transmitted from postfix pipe feature to autoresponse bash script and how i can solve this? (Best way to solve of course). - If that is not clear/possible, can anyone enlighten me how i can pass a variable from bash script to my Perl script and maybe change the value in Perl script and passing back either the original (unchanged) value or a changed one other way as do a print command in Perl and redirect stdout? - Or how i can redirect stdout when my script runs under postfix pipe feature without complaints from postfix? - or someone can recommend another package like autoresponse, that works and have comparable features as autoresponse? Sorry for the long mail, but i think i need to explain in full detail to be understandable. If you have any further questions, please ask. I was unsure if i shall add some logfile information to my first mail (it is already much too long :( ), but will do gladly if you need them and request for it. Thank you all for reading and your effort and maybe a shed of light in my dark brain. TIAVM Joerg
Re: Autoresponse problem (Sorry for a bit OT - but somehow Postfix related)
> - or someone can recommend another package like autoresponse, that works and > have comparable features as autoresponse? how about using sieve language for autoreponder: http://wiki.dovecot.org/LDA/Sieve#Vacation_auto-reply-1 It worked fine last time on my postfix+dovecot setup -- Eero
RE: Change error messages returned by Postfix
> -Original Message- > From: owner-postfix-us...@postfix.org [mailto:owner-postfix- > us...@postfix.org] On Behalf Of Victor Duchovni > Sent: Monday, January 03, 2011 8:00 PM > To: postfix-users@postfix.org > Subject: Re: Change error messages returned by Postfix > > On Mon, Jan 03, 2011 at 07:44:51PM +0100, Ralf Hildebrandt wrote: > > > * Wietse Venema : > > > > > 421-4.4.2 host.example.com Error: timeout exceeded > > > 421 4.4.2 For assistance, contact the helpdesk at 800-555-0101 > > > > > > I wonder how many calls you would actually get for that. After updating our anti-spam rules/rDNS checks: probably more than expected Would it be an option to get something like the thing below for all error messages? 421 4.4.2 host.example.com Error: timeout exceeded - for more information see http://postmaster.domain.tld/[ip]-[code].html Where [ip] has to be replaced with the client IP and [code] has to be replaced with the error code (421 in this example). Using a certain error code for certain types of blocks would make it possible to display the correct page directly (or at least limit the input required from the person following the link). > > Almost none, because users cannot read [bounce messages]. > > They understand that the message did not arrive: > > http://funstoo.blogspot.com/2010/12/what-we-say-to-dogs-what-they- > hear.html > > This said, in a B2B context, a less experienced postmaster of a > remote domain may in some cases benefit from a link to a more detailed > explanation of an SMTP reject message. A fixed suffix for SMTP error > responses is probably the right cost/benefit trade-off. Informing other postmasters of a remote domain/server is the main reason we are looking for this option (or have to manually change things). If they could find why it was blocked and the reason it was blocked would probably reduce the support calls about the mailservers. Regards, Mark
Re: Change error messages returned by Postfix
Wietse Venema: > Instead of making every response configurable, a more practical > solution is to configure ONE response that gets appended to ALL > the SMTP server's reject messages. Effectively, this turns the > one-line reject into a two-line response, one chosen by Postfix > and one chosen by the system adminstrator. I have added this yesterday to Postfix 2.8. This provides a fixed text that is added as an extra line to server responses. Wietse smtpd_reject_contact_information (default: empty) Optional contact information that is appended after each SMTP server 4XX or 5XX response. Example: /etc/postfix/main.cf: smtpd_reject_contact_information = For assistance, call 800-555-0101 Server response: 550-5.5.1
RE: odd pickup maildrop permission denied warnings
Wietse wrote:
>
> The permissons are normal, therefore you have either
>
> - A corruped file system (not possible, since postcat can read the
> file).
>
> - Other file OR directory permission attributes that the "ls"
> command does not show but that allow you to view the files with
> sudo postcat.
>
> - Other "security" features (SeLinux etc) that don't allow the
> pickup daemon to open files owned by the postfix user. Such files
> exist when you move queue files with "postsuper -r".
>
> Wietse
Wietse,
Thank you, it was exactly that. In case this hits anyone else, here's the
workaround for SELinux users:
( make sure you are in enforcing mode -- run 'getenforce' -- if not, this is
not your issue )
$ /etc/init.d/postfix stop
$ setenforce permissive
$ /etc/init.d/postfix start
{ watch /var/spool/maildrop until it empties out }
$ setenforce enforcing
( the postfix restart is not needed; I just wanted to make sure I triggered a
maildrop run as quickly as possible so I could spend the least amount of time
in SELinux permissive mode. )
Best,
Aaron
---
Aaron Bennett
Manager of Systems Administration
Clark University ITS
Re: Change error messages returned by Postfix
Am 04.01.2011 12:59, schrieb Wietse Venema: Wietse Venema: Instead of making every response configurable, a more practical solution is to configure ONE response that gets appended to ALL the SMTP server's reject messages. Effectively, this turns the one-line reject into a two-line response, one chosen by Postfix and one chosen by the system adminstrator. I have added this yesterday to Postfix 2.8. This provides a fixed text that is added as an extra line to server responses. Wietse smtpd_reject_contact_information (default: empty) Optional contact information that is appended after each SMTP server 4XX or 5XX response. Example: /etc/postfix/main.cf: smtpd_reject_contact_information = For assistance, call 800-555-0101 Server response: 550-5.5.1 Cool. Thanks. Can this be configured in a multi-domain environment e.g. via restriction classes in a way where every domain admin can supply his own contact details?
Re: qmgr killed by signal 15 [solved]
As it turned out, the problem was with 1-2-3 Systems' VPS service. Through this mailing list I found another person who was having the exact same problem with me with qmgr being killed constantly, who also happened to be hosted on the same physical box as me at 1-2-3 Systems. Since we were the only two people that either of us could find anywhere on the 'net that was having this issue with Postfix, it was pretty clear that this one thing we both had in common must be the cause. I opened a ticket with 1-2-3 Systems, and they eventually found and fixed the problem on their box, which solved it for both of us. Unfortunately, 1-2-3 Systems refuses to tell me exactly what they found or how they fixed it, even after I asked them several times (they will only give me very vague answers such as "it was a problem between the VPS and host, and we corrected it"), but it was clearly something outside of the VPS environment that was beyond my control. My assumption is that they are running paravirtualization and that their host system had some sort of monitoring script that was routinely killing postfix related processes within VPSes running on the host. That's just a guess, but it's the best I have. In any event it's fixed. Thanks to everyone who replied! - Jeff On 12/20/2010 1:22 PM, Jeff Morris wrote: On 12/18/2010 11:03 PM, Victor Duchovni wrote: postfix/master[20377]: warning: process /usr/libexec/postfix/qmgr pid 20380 killed by signal 15 This is SIGTERM. Are you running "postfix stop" frequently? No. In fact I'm not running it at all. In fact in the interest of troubleshooting this, I have re-installed my VPS from a clean CentOS 5.5 image, and done *nothing* but "yum erase sendmail", "yum install postfix", "service postfix start". And I still get the same problem. And only on this one VPS with 123Systems, not on any of the dozens of other Postfix mail servers I am responsible for. Don't "restart" Postfix every 5 minutes. I'm not. As I said, the master.cf has "wakeup" set to 300 seconds, but this is the default setting, not something I modified, and it is the same setting as all of my other servers (which do not exhibit this problem.) If it were not there, then I don't believe that qmgr would run at all, except when a connection comes in on port 25. I haven't looked at the postfix source code, but it seems like postfix is smart enough to check for qmgr when a connection comes in, sees that it isn't running, and spawns it. Likewise, every 5 minutes it's trying to wake up qmgr, seeing that it's not running, and spawning it. In other words, postfix is trying it's darndist to keep things running, but *something* is sending a SIGTERM to qmgr several seconds after it starts up. And as Wietse mentioned in a separate reply, we can rule out that it's Postfix which is sending the SIGTERM to qmgr, because if it were, it would not be logging the warning. And not only am I running with a clean VPS image, I've even tried killing everything non-essential, to the point where basically all that's running on the VPS is init, postfix, and sshd, and yet the problem persists. There's no cron running, no scripts, no other deamons, nothing. Interestingly, I also received one other off-list response to my email from someone else who is experiencing the exact smae problem. Despite *hours* of Googling, he is the only other person I've managed to come across with this same issue, and here's the kicker... he's on a VPS with 123Systems as well. So there's the commonality. I'm not one to believe in coincidences, so now I'm pretty much convinced that there must be something that 123Systems is doing which is causing this. Either they have some sort of monitoring running on the host which is somehow sending a SIGTERM to qmgr within the guest, or they have done something to their default CentOS image which is causing it (althoguh for the life of me I can't imagine what, since even if I replace the Postfix config files with the config from my other, working VPS, I still get this same behavior.) I have opened a ticket with 123Systems to see if they can shed any light on this. I'll post a follow-up here when I have anything new to report. Thanks. - Jeff
Re: Change error messages returned by Postfix
John Adams: > > Example: > > > > /etc/postfix/main.cf: > > smtpd_reject_contact_information = For assistance, call > > 800-555-0101 > > > > Server response: > > > > 550-5.5.1 > 550 5.5.1 For assistance, call 800-555-0101 > > > > This feature is available in Postfix 2.8. > > Cool. Thanks. > Can this be configured in a multi-domain environment e.g. via > restriction classes in a way where every domain admin can supply his > own contact details? This is a static main.cf parameter like myhostname, not a dynamic table lookup result like DNSBL response maps. I don't understand how one would make this configurable depending on client input. FYI the time window for Postfix 2.8 changes is closing really soon. If there remains controversy on how this feature should work then it should not be included with the Postfix 2.8 stable release. Wietse
Re: Change error messages returned by Postfix
On Tue, Jan 04, 2011 at 01:24:51PM +0100, John Adams wrote: >> 550-5.5.1> 550 5.5.1 For assistance, call 800-555-0101 >> >> This feature is available in Postfix 2.8. > > Cool. Thanks. > Can this be configured in a multi-domain environment e.g. via restriction > classes in a way where every domain admin can supply his own contact > details? If you want multiple Postfix personalities, use multiple Postfix instances: http://www.postfix.org/MULTI_INSTANCE_README.html If you have light-weight instances via master.cf smtpd/inet services bound to secondary IPs, you can configure each instance with a different response via "-o" overrides. Otherwise, the feature is correctly designed to append optional contact information for the *system administrator* or a troubleshooting help URL for senders having trouble delivering email via the *system* in question. -- Viktor.
Re: Change error messages returned by Postfix
Am 04.01.2011 14:59, schrieb Victor Duchovni: On Tue, Jan 04, 2011 at 01:24:51PM +0100, John Adams wrote: 550-5.5.1 Cool. Thanks. Can this be configured in a multi-domain environment e.g. via restriction classes in a way where every domain admin can supply his own contact details? If you want multiple Postfix personalities, use multiple Postfix instances: http://www.postfix.org/MULTI_INSTANCE_README.html That is very interesting. Thanks for the link. If you have light-weight instances via master.cf smtpd/inet services bound to secondary IPs, you can configure each instance with a different response via "-o" overrides. Otherwise, the feature is correctly designed to append optional contact information for the *system administrator* or a troubleshooting help URL for senders having trouble delivering email via the *system* in question. Yes, I understand that. But that is not how I experienced the world. Usually, if person X from domain X could not mail to person Z from domain Z for a reject reason given by mail provider M, then X would call Z (I cannot send you mails) and Z would call M (X cannot send us mails). Does this sound reasonable to you?
Re: Change error messages returned by Postfix
On Tue, Jan 04, 2011 at 03:09:01PM +0100, John Adams wrote: > Yes, I understand that. But that is not how I experienced the world. > Usually, if person X from domain X could not mail to person Z from domain Z > for a reject reason given by mail provider M, then X would call Z (I cannot > send you mails) and Z would call M (X cannot send us mails). Does this > sound reasonable to you? The mail provider implements all technologies associated with the mail system, including any troubleshooting HTML for legitimate servers who encounter difficulties. Sure, if the sender knows the recipient domain's (M's client's) contact information he/she can start there, but M's SMTP servers should in most cases refer the sender to M's help page and M's contact information. The new 2.8 feature is a reasonable cost/benefit trade-off. -- Viktor.
RE: Change error messages returned by Postfix
Wietse Venema: > Wietse Venema: > > Instead of making every response configurable, a more practical > > solution is to configure ONE response that gets appended to ALL > > the SMTP server's reject messages. Effectively, this turns the > > one-line reject into a two-line response, one chosen by Postfix > > and one chosen by the system adminstrator. > > I have added this yesterday to Postfix 2.8. This provides a fixed > text that is added as an extra line to server responses. > > Wietse > > smtpd_reject_contact_information (default: empty) >Optional contact information that is appended after each SMTP > server >4XX or 5XX response. > >Example: > >/etc/postfix/main.cf: >smtpd_reject_contact_information = For assistance, call 800- > 555-0101 > >Server response: > >550-5.5.1 unknown >550 5.5.1 For assistance, call 800-555-0101 > >This feature is available in Postfix 2.8. Thank you. Is it possible to let this new setting contain something that contains the client IP and/or something so we could identify it with a script? That way we could make it contain more information directly, however that is more a "nice to have" than show stopper for us. Regards, Mark
Re: body_checks ... can a header be inserted?
On Thu, Dec 30, 2010 at 17:27, Wietse Venema wrote: > Phil Howard: >> With body checks, is there a way to insert a header or otherwise flag >> the mail in a way CMUSieve could detect? > > Unlike some software, Postfix behaves as documented, so you can > easily establish from the manpage how the prepend action works. So basically, the answer is "no". Behaving as documented is good. But is it the case that every feature is documented and none are left out? -- sHiFt HaPpEnS!
Re: Change error messages returned by Postfix
On Tue, Jan 04, 2011 at 03:36:41PM +0100, Mark Scholten wrote: > >Server response: > > > >550-5.5.1 > unknown > >550 5.5.1 For assistance, call 800-555-0101 > > > >This feature is available in Postfix 2.8. > > Thank you. Is it possible to let this new setting contain something that > contains the client IP and/or something so we could identify it with a > script? Identify what with a script? - The SMTP reject message appears in the receiving Postfix system's logs, where the client's IP is always part of the logged context. - The SMTP reject message appears in the client system's logs. The client knows its own IP. - The SMTP reject message appears in the non-delivery DSN generated by the client system and returned to the envelope sender. This will in most cases (qmail's non-MIME bounces aside) contain the standard DSN fields, including the reporting MTA name. The static appended response is for *contact* information or a reference web-site. -- Viktor.
Re: body_checks ... can a header be inserted?
On Tue, Jan 04, 2011 at 09:47:10AM -0500, Phil Howard wrote: > > Unlike some software, Postfix behaves as documented, so you can > > easily establish from the manpage how the prepend action works. > > So basically, the answer is "no". > > Behaving as documented is good. But is it the case that every feature > is documented and none are left out? Postfix features are developed after or concurrently with the reference documentation. There are no hidden features. Undocumented features are never adopted into Postfix. If it is not documented, it is not a feature. This *should* not be surprising. Not all the internal architectural details are documented, these are not features. Rather, an expert administrator could use a deep understanding of the internal architecture to more easily tune and troubleshoot a Postfix system. The internal architecture is subject to change, and users must not depend on it not changing. Some of the internals are described in the OVERVIEW, QSHAPE_README and SCHEDULER_README documents. -- Viktor.
Re: body_checks ... can a header be inserted?
On Tue, Jan 4, 2011 at 10:12, Victor Duchovni wrote: > On Tue, Jan 04, 2011 at 09:47:10AM -0500, Phil Howard wrote: > >> > Unlike some software, Postfix behaves as documented, so you can >> > easily establish from the manpage how the prepend action works. >> >> So basically, the answer is "no". >> >> Behaving as documented is good. But is it the case that every feature >> is documented and none are left out? > > Postfix features are developed after or concurrently with the reference > documentation. There are no hidden features. Undocumented features are > never adopted into Postfix. > > If it is not documented, it is not a feature. This *should* not be > surprising. > > Not all the internal architectural details are documented, these are not > features. Rather, an expert administrator could use a deep understanding > of the internal architecture to more easily tune and troubleshoot a > Postfix system. The internal architecture is subject to change, and users > must not depend on it not changing. Some of the internals are described > in the OVERVIEW, QSHAPE_README and SCHEDULER_README documents. And that is part of my thinking. There MAY have been some "constructive" way to use different elements of Postfix that could have achieved the same effect, which might be obvious only to those who have the deep understanding (I am not one of those). The fact that PREPEND only inserts at that point where the triggering line is, is the limiting factor. In header checks, that's OK for inserting a header, although one does not have control where that insert happens (normally I'd want to insert any new header at the top, although for my current need, that won't matter). I'm assuming the header checks and body checks is implemented as some code that sees a stream, rather than the whole message (especially when doing body checks), so I'm guessing it would be non-trivial to add a new action in a future version that would do a "prepend to the top of headers". So I'm thinking about an alternative where I do a routine prepend of some very bizarre text (since it now inside the message body), that would be very unlikely to ever be in any message, and follow that with an external filter by inserting my own code between Postfix and Amavis (unless there is some means inside Amavis to hook in to do this) to store the message to a temporary file while looking for that bizarre text, and if found add the header when the message is sent on to Amavis (which later sends it back to Postfix). -- sHiFt HaPpEnS!
Re: Autoresponse problem (Sorry for a bit OT - but somehow Postfix related)
Le 04/01/2011 10:26, Joerg Toellner a écrit : > [snip] > > - Does anyone have an idea/hint for me why some addresses loose the TLD part > when transmitted from postfix pipe feature to autoresponse bash script and > how i can solve this? (Best way to solve of course). > > - If that is not clear/possible, can anyone enlighten me how i can pass a > variable from bash script to my Perl script and maybe change the value in > Perl script and passing back either the original (unchanged) value or a > changed one other way as do a print command in Perl and redirect stdout? > We have no idea how you call your script. (we need to see the configuration lines you use to run the script, and examples of working and non working addresses. use @example.com, @example.org, @example.net or @whateveryouwant.example to protect private domains). > - Or how i can redirect stdout when my script runs under postfix pipe > feature without complaints from postfix? > I have no idea what you mean here. do you run a perl script that spawns the bash script? if so open(OUT, "|/path/toscript") ... or are you trying to do a more elaborate IPC mechanisme? if so, you're going for much more complexity than necessary. > - or someone can recommend another package like autoresponse, that works and > have comparable features as autoresponse? > I have no idea what "autoresponse" is, so can't compare its features! - if you use dovecot for delivery, try its sieve. - with local users, the old "vacation" program has been known to work for ages now, and implements many "best practices" for auto-reponders. - postfixadmin has a vacation.pl script. but I don't know its status now. ... > Sorry for the long mail, but i think i need to explain in full detail to be > understandable. If you have any further questions, please ask. I was unsure > if i shall add some logfile information to my first mail (it is already much > too long :( ), when posting logs, do not enable verbose logging unless explicitely asked. In general, we like to see log lines that "demonstrate" the problem and (when applicable) lines for a working case. > but will do gladly if you need them and request for it. > > Thank you all for reading and your effort and maybe a shed of light in my > dark brain. > > TIAVM > Joerg >
Re: body_checks ... can a header be inserted?
On Tue, Jan 04, 2011 at 10:53:56AM -0500, Phil Howard wrote: > And that is part of my thinking. All the features that you can use are documented. The internals that you can use to *reason* about the behaviour of the system when things go wrong are less easily described. > There MAY have been some > "constructive" way to use different elements of Postfix that could > have achieved the same effect, which might be obvious only to those > who have the deep understanding (I am not one of those). The fact > that PREPEND only inserts at that point where the triggering line is, > is the limiting factor. In header checks, that's OK for inserting a > header, although one does not have control where that insert happens > (normally I'd want to insert any new header at the top, although for > my current need, that won't matter). The feature behaves exactly as documented, as are all the built-in content inspection features: http://www.postfix.org/BUILTIN_FILTER_README.html > I'm assuming the header checks and body checks is implemented as some > code that sees a stream, rather than the whole message (especially > when doing body checks), so I'm guessing it would be non-trivial to > add a new action in a future version that would do a "prepend to the > top of headers". You don't need to guess. http://www.postfix.org/BUILTIN_FILTER_README.html#limitations Header/body checks cannot filter on a combination of message headers or body lines. Header/body checks examine content one message header at a time, or one message body line at a time, and cannot carry a decision over to the next message header or body line. > So I'm thinking about an alternative where I do a > routine prepend of some very bizarre text (since it now inside the > message body), that would be very unlikely to ever be in any message, > and follow that with an external filter by inserting my own code > between Postfix and Amavis (unless there is some means inside Amavis > to hook in to do this) to store the message to a temporary file while > looking for that bizarre text, and if found add the header when the > message is sent on to Amavis (which later sends it back to Postfix). Just do the original inspection in that filter, where you get the option to base64-decode the content, parse the HTML, ... My body checks are basically limited to: /^Below is the result of your feedback form./ REJECT ... Perhaps it should be possible to prepend a header in body-checks, this is within the architectural capabilities of the current queue-file format, which accomodates similar after-the-fact edits via milters. There would probably need to be a duplicate elimination table, so that each "PREPEND_HEADER" action in body_checks prepends at most one instance of any given header. No detailed design has been proposed to fill this need. -- Viktor.
Re: body_checks ... can a header be inserted?
Le 04/01/2011 16:53, Phil Howard a écrit : > [snip] So I'm thinking about an alternative where I do a > routine prepend of some very bizarre text (since it now inside the > message body), that would be very unlikely to ever be in any message, > and follow that with an external filter by inserting my own code > between Postfix and Amavis (unless there is some means inside Amavis > to hook in to do this) to store the message to a temporary file while > looking for that bizarre text, and if found add the header when the > message is sent on to Amavis (which later sends it back to Postfix). > with amavis, setup a spamassassin rule that matches your bizarre text. fopr instance body FOO_BAR_RULE /SomeExpression/i score FOO_BAR_RULE 0.1 (0.1 is small enough to not alter spam status). then "FOO_BAR_RULE" will appear in the X-Spam-Status, which your sieve/whatever script can catch. if you want more, then you can probably create a before_send hook in amavis.
Re: Change error messages returned by Postfix
Victor Duchovni: > On Tue, Jan 04, 2011 at 03:36:41PM +0100, Mark Scholten wrote: > > > >Server response: > > > > > >550-5.5.1 > > unknown > > >550 5.5.1 For assistance, call 800-555-0101 > > > > > >This feature is available in Postfix 2.8. > > > > Thank you. Is it possible to let this new setting contain something that > > contains the client IP and/or something so we could identify it with a > > script? > > Identify what with a script? > >[talk about stuff in logfiles] I'm just guessing, but I suspect that this is about making trouble shooting easier, like putting some unique "trouble ticket" like string in the 4XX or 5XX response that is easily located in the logfile, so they can quickly locate the entire session in the log. smtpd_reject_contact_information = For assistance, call 800-555-0101 with ticket $instance (where instance is the SMTP server PID and a sequence number, it's the same attribute used in the SMTP policy server protocol). This is not as simple as it sounds (apart from the need to provide the $name expansion module). Postfix currently does NOT log the contact footer to the maillog file. There are tons of places in Postfix that reject a command (e.g., bad syntax, or some requested feature not available) without logging that the command was rejected. That would just make it too easy for the bad guys to flood the maillog file with garbage. I could change postfix to ALWAYS log the contact footer to the maillog fil3, but then you'd get lots of contact footers in the maillog without any indication of why they were logged. Wietse
Re: body_checks ... can a header be inserted?
Phil Howard: > I'm assuming the header checks and body checks is implemented as some > code that sees a stream, rather than the whole message (especially > when doing body checks), so I'm guessing it would be non-trivial to > add a new action in a future version that would do a "prepend to the > top of headers". So I'm thinking about an alternative where I do a This is how header_checks/body_checks work. They see content as mail streams through Postfix. With Milter support, it is possible to change contentm, but the Milter head/body are done only after the entire message is already stored in the queue file. That is, Milter sees head/body not while mail streams through Postfix, but rather, after the fact. Wietse
Re: body_checks ... can a header be inserted?
On Tue, Jan 4, 2011 at 11:14, Victor Duchovni wrote: > On Tue, Jan 04, 2011 at 10:53:56AM -0500, Phil Howard wrote: >> I'm assuming the header checks and body checks is implemented as some >> code that sees a stream, rather than the whole message (especially >> when doing body checks), so I'm guessing it would be non-trivial to >> add a new action in a future version that would do a "prepend to the >> top of headers". > > You don't need to guess. > > http://www.postfix.org/BUILTIN_FILTER_README.html#limitations > > Header/body checks cannot filter on a combination of message > headers or body lines. Header/body checks examine content one > message header at a time, or one message body line at a time, > and cannot carry a decision over to the next message header or > body line. At this point I'm looking at this in terms of "can the needed feature be added". The implementation of the test itself, and the implementation of how the test is connected into the rest of the system matter. The test itself dictates the behavior. How it's connected in can (and was my guess that it does) limit the possibilities of adding a like test. In other words, for the test itself to be changed (as a new kind of test) to do what I need, it would either need random access to the message file (which cannot happen here if the message is not yet stored as a file), or has separated headers. For example an implementation of the surrounding infrastructure that separated the headers and store them, alone, in a temporary file or even a temporary buffer, and processed the remainder of the message as a text line stream, could modify the headers on the side. My assumption (guess) is that Postfix doesn't do this. But a description of the test itself doesn't confirm that because the simpler test can still be done in all the variety of possible environments. >> So I'm thinking about an alternative where I do a >> routine prepend of some very bizarre text (since it now inside the >> message body), that would be very unlikely to ever be in any message, >> and follow that with an external filter by inserting my own code >> between Postfix and Amavis (unless there is some means inside Amavis >> to hook in to do this) to store the message to a temporary file while >> looking for that bizarre text, and if found add the header when the >> message is sent on to Amavis (which later sends it back to Postfix). > > Just do the original inspection in that filter, where you get the option > to base64-decode the content, parse the HTML, ... > > My body checks are basically limited to: > > /^Below is the result of your feedback form./ REJECT ... Rejecting is not an option, per local policy, for any message based on its contents. The only case where we can do a reject is more easily done as an access rule in the firewall (e.g. for a DoS attack). > Perhaps it should be possible to prepend a header in body-checks, this > is within the architectural capabilities of the current queue-file > format, which accomodates similar after-the-fact edits via milters. > > There would probably need to be a duplicate elimination table, so that > each "PREPEND_HEADER" action in body_checks prepends at most one instance > of any given header. > > No detailed design has been proposed to fill this need. Separation of headers and body for the purpose of modifying message content would be helpful. A "PREPEND_TO_HEADERS" action would then be useful if that can be done. A "Received" header gets prepended. But that is easily doable before any other content processing is done. But at this point I'm going to spend my time either trying to find another way to do this, or find a way to not need to do this (e.g. do more tests in Amavis or Spamassassin, depending on what capabilities exist there, which I am still getting into). In the past, I've always done anti-spam actions by blacklists or whitelists, and rejecting everything that comes from anywhere spam comes from. But this is a new case where such rejection is not an option. The plan is if it looks like a virus or spam, it goes into a virus or spam subfolder. Blacklists are probably not in the plan. Whitelists might be as a means to bypass spam checking. -- sHiFt HaPpEnS!
Re: body_checks ... can a header be inserted?
On Tue, Jan 4, 2011 at 11:14, mouss wrote: > with amavis, setup a spamassassin rule that matches your bizarre text. > fopr instance > > body FOO_BAR_RULE /SomeExpression/i > score FOO_BAR_RULE 0.1 > (0.1 is small enough to not alter spam status). > > then "FOO_BAR_RULE" will appear in the X-Spam-Status, which your > sieve/whatever script can catch. At that point it probably won't matter so much what the score is, as I will be committing it to the spam subfolder. > if you want more, then you can probably create a before_send hook in amavis. Hopefully I can keep this simple ... if it smells spammy, it goes into the spam subfolder. Then the user can look there for missing stuff if needed, but it won't be making their phones buzz. So many people checking their mail by phone now days changes priorities. -- sHiFt HaPpEnS!
Re: Change error messages returned by Postfix
On Tue, Jan 04, 2011 at 11:33:25AM -0500, Wietse Venema wrote: > > > Thank you. Is it possible to let this new setting contain something that > > > contains the client IP and/or something so we could identify it with a > > > script? > > > > Identify what with a script? > > > >[talk about stuff in logfiles] > > I'm just guessing, but I suspect that this is about making trouble > shooting easier, like putting some unique "trouble ticket" like > string in the 4XX or 5XX response that is easily located in the > logfile, so they can quickly locate the entire session in the log. > > smtpd_reject_contact_information = > For assistance, call 800-555-0101 with ticket $instance > > (where instance is the SMTP server PID and a sequence number, it's > the same attribute used in the SMTP policy server protocol). > > This is not as simple as it sounds (apart from the need to provide > the $name expansion module). > > Postfix currently does NOT log the contact footer to the maillog > file. There are tons of places in Postfix that reject a command > (e.g., bad syntax, or some requested feature not available) without > logging that the command was rejected. That would just make it too > easy for the bad guys to flood the maillog file with garbage. > > I could change postfix to ALWAYS log the contact footer to the > maillog fil3, but then you'd get lots of contact footers in the > maillog without any indication of why they were logged. I don't think that the 50X or other unlogged error responses should start logging "disembodied" contact footers. If the contact footer is to log some unique identifier, then just that identifier could perhaps be added as a standard element of the log_whatsup() message... May have to initialize the instance id on entry to mail_cmd() rather than when it is (about to be) accepted. The smtpd_chat_reply() routine would then append the same instance id to the contact footer. -- Viktor.
Re: body_checks ... can a header be inserted?
On Tue, Jan 04, 2011 at 11:39:01AM -0500, Phil Howard wrote: > In other words, for the test itself to be changed (as a new kind of > test) to do what I need, it would either need random access to the > message file (which cannot happen here if the message is not yet > stored as a file), or has separated headers. Neither is necessary. The post-milter Postfix queue-file is a linked-list of records, and new records can be added logically in the middle of the file, after the fact, via pointer-records. > > No detailed design has been proposed to fill this need. > > Separation of headers and body for the purpose of modifying message > content would be helpful. A "PREPEND_TO_HEADERS" action would then be > useful if that can be done. A "Received" header gets prepended. But > that is easily doable before any other content processing is done. To propose an enhanced design, you'd have to study the current design. The integration of milter checks into Postfix makes it possible to use the new capabilities to enhance the original built-in checks. Milters look at the whole message and finally emit a list of headers to insert. The built-in checks act on one header or body line at a time. For header-insertion to make sense in body checks there needs to be a sensible duplicate elimination strategy. Is there a clear consensus on how body-line at a time header insertion should behave? A complex design would set flags for each feature identified in the message, and then provide some way to generate actions based on the flags set at the end of the message. "Just write a content filter or milter" is probably the better option. A less complex design would just eliminate duplicate headers, and insert all the unique headers when the message end is reached. Would this be sufficiently useful to enough users? -- Viktor.
Re: Change error messages returned by Postfix
Victor Duchovni: > > I'm just guessing, but I suspect that this is about making trouble > > shooting easier, like putting some unique "trouble ticket" like > > string in the 4XX or 5XX response that is easily located in the > > logfile, so they can quickly locate the entire session in the log. > > > > smtpd_reject_contact_information = > > For assistance, call 800-555-0101 with ticket $instance > > > > (where instance is the SMTP server PID and a sequence number, it's > > the same attribute used in the SMTP policy server protocol). > > > > This is not as simple as it sounds (apart from the need to provide > > the $name expansion module). > > > > Postfix currently does NOT log the contact footer to the maillog > > file. There are tons of places in Postfix that reject a command > > (e.g., bad syntax, or some requested feature not available) without > > logging that the command was rejected. That would just make it too > > easy for the bad guys to flood the maillog file with garbage. > > > > I could change postfix to ALWAYS log the contact footer to the > > maillog fil3, but then you'd get lots of contact footers in the > > maillog without any indication of why they were logged. > > I don't think that the 50X or other unlogged error responses should > start logging "disembodied" contact footers. If the contact footer is > to log some unique identifier, then just that identifier could perhaps > be added as a standard element of the log_whatsup() message... Some people might disagree and say that Postfix should log ALL rejects (including bad syntax/unsupported command). Currently, it leaves helpdesk people scratching their head what to look for in the maillog file when someone asks for help with a mail delivery problem. This requires more than simply logging all 4XX and 5XX responses, because you also need to know log the command itself that is being rejected. That is too much change before the Postfix 2.8 release. What I could do for now is a contact footer with dynamic context such as the SMTP server PID and client IP address. That information is already in the maillog file. So this would change the feature to: smtpd_reject_contact_information = For assistance, call 800-555-0101 (pid=$pid, client=$client_addr) The result would look like: 554-5.5.1 : Recipient address reject: User unknown 554 5.5.1 For assistance, call 800-555-0101 (pid=7283, client=192.168.1.248) The helpdesk person then looks for "[7283]" and "192.168.1.248" in the maillog file. This would lift some, but not all, of the mystery with commands that Postfix rejects (syntax, etc.) without logging them. Wietse
Re: Change error messages returned by Postfix
On Tue, Jan 04, 2011 at 12:54:24PM -0500, Wietse Venema wrote: > What I could do for now is a contact footer with dynamic context > such as the SMTP server PID and client IP address. That information > is already in the maillog file. > > So this would change the feature to: > > smtpd_reject_contact_information = > For assistance, call 800-555-0101 (pid=$pid, client=$client_addr) > > The result would look like: > > 554-5.5.1 : Recipient address reject: User unknown > 554 5.5.1 For assistance, call 800-555-0101 (pid=7283, > client=192.168.1.248) > > The helpdesk person then looks for "[7283]" and "192.168.1.248" in > the maillog file. This would lift some, but not all, of the mystery > with commands that Postfix rejects (syntax, etc.) without logging > them. This would likely need to also be implemented in postscreen. :-( If keyword-substitution is supported, apart from $pid, and $client_addr also $rfc822_date would perhaps be useful to help search logs for the right day. With this, there is no need to separately log the helpful footer, the information is already present in the receiving server logs, the footer makes it more readily available to sender sites to aid in event correlation. -- Viktor.
Re: Change error messages returned by Postfix
Victor Duchovni: > On Tue, Jan 04, 2011 at 12:54:24PM -0500, Wietse Venema wrote: > > > What I could do for now is a contact footer with dynamic context > > such as the SMTP server PID and client IP address. That information > > is already in the maillog file. > > > > So this would change the feature to: > > > > smtpd_reject_contact_information = > > For assistance, call 800-555-0101 (pid=$pid, client=$client_addr) > > > > The result would look like: > > > > 554-5.5.1 : Recipient address reject: User unknown > > 554 5.5.1 For assistance, call 800-555-0101 (pid=7283, > > client=192.168.1.248) > > > > The helpdesk person then looks for "[7283]" and "192.168.1.248" in > > the maillog file. This would lift some, but not all, of the mystery > > with commands that Postfix rejects (syntax, etc.) without logging > > them. > > This would likely need to also be implemented in postscreen. :-( If > keyword-substitution is supported, apart from $pid, and $client_addr > also $rfc822_date would perhaps be useful to help search logs for the > right day. PID logging isn't useful with postscreen(8) because there is only one process, so I'll add a localtime attribute. The rfc822_date string seems too long to be useful; we need something that people can use in a phone call. > With this, there is no need to separately log the helpful footer, the > information is already present in the receiving server logs, the footer > makes it more readily available to sender sites to aid in event correlation. Yes, that was the idea, giving the client some of the session attributes that are already in the logs. Wietse
Re: body_checks ... can a header be inserted?
Le 04/01/2011 17:44, Phil Howard a écrit : > On Tue, Jan 4, 2011 at 11:14, mouss wrote: > >> with amavis, setup a spamassassin rule that matches your bizarre text. >> fopr instance >> >> body FOO_BAR_RULE /SomeExpression/i >> score FOO_BAR_RULE 0.1 >> (0.1 is small enough to not alter spam status). >> >> then "FOO_BAR_RULE" will appear in the X-Spam-Status, which your >> sieve/whatever script can catch. > > At that point it probably won't matter so much what the score is, as I > will be committing it to the spam subfolder. > > >> if you want more, then you can probably create a before_send hook in amavis. > > Hopefully I can keep this simple ... if it smells spammy, it goes into > the spam subfolder. Then the user can look there for missing stuff if > needed, but it won't be making their phones buzz. > > So many people checking their mail by phone now days changes priorities. > another idea is to use the FILTER action to pass these messages to a specific listener (smtpd) which prepends a header or rewrites the recipient to recipient+s...@example.com (via a specific cleanup).
Re: Change error messages returned by Postfix
"Wietse Venema" > Example: > > /etc/postfix/main.cf: > smtpd_reject_contact_information = For assistance, call 800-555-0101 > > Server response: > > 550-5.5.1 550 5.5.1 For assistance, call 800-555-0101 > > This feature is available in Postfix 2.8. This is a static main.cf parameter like myhostname, not a dynamic table lookup result like DNSBL response maps. I don't understand how one would make this configurable depending on client input. FYI the time window for Postfix 2.8 changes is closing really soon. If there remains controversy on how this feature should work then it should not be included with the Postfix 2.8 stable release. Wietse How am I supposed to figure out and dynamically insert the remote sys admin's phone number, for every domain that sends us mail? So shouldn't the default text be? smtpd_reject_contact_information = Sender, for assistance call YOUR system admin (not us) and tell them to fix the problem Just kidding! (sort of) But I don't see the point of adding more generic information in the response. We reject plenty of mail via RBLs, but we rarely get an email asking us why an RBL blocked email was rejected. The client specific url included in the RBL reject seems to work very well. If the remote admin calls or emails, I can just point them to the url and tell them to fix their servers. The only rejects that I get calls or emails about are: reject_non_fqdn_helo_hostname, reject_unknown_helo_hostname, reject_unknown_client_hostname, reject_unknown_reverse_client_hostname If these four rejects had individually configurable error text, it would help a lot. Instead of Helo command rejected: Host not found, I could choose to return: Helo command rejected: Host not found; see example.tld?helo=somedomain.local Then I can provide detailed info on why the email was rejected, and provide links to best practices and resources on fixing their problem. For each of these rejects, the client IP or host name that triggered the reject is already included in the response. So it seems like all we need is a way to set or add to the response text, and a variable that holds the client IP or hostname.
Re: Change error messages returned by Postfix
On Tue, Jan 04, 2011 at 02:09:07PM -0500, Wietse Venema wrote: > > This would likely need to also be implemented in postscreen. :-( If > > keyword-substitution is supported, apart from $pid, and $client_addr > > also $rfc822_date would perhaps be useful to help search logs for the > > right day. > > PID logging isn't useful with postscreen(8) because there is only > one process, so I'll add a localtime attribute. The rfc822_date > string seems too long to be useful; we need something that people > can use in a phone call. So long as localtime is date + time: often help queries get to the right people days after the original event, and it is important to know when the reported issue is purported to have happened. -- Viktor.
Re: body_checks ... can a header be inserted?
On Tue, Jan 4, 2011 at 14:20, mouss wrote: > another idea is to use the FILTER action to pass these messages to a > specific listener (smtpd) which prepends a header or rewrites the > recipient to recipient+s...@example.com (via a specific cleanup). That's an interesting idea. I'll give that one a try. I'm just doing headers to flag things for sieve now. -- sHiFt HaPpEnS!
Re: Change error messages returned by Postfix
On Tue, Jan 04, 2011 at 02:32:45PM -0500, pf at alt-ctrl-del.org wrote: > But I don't see the point of adding more generic information in the > response. Providing a URL of a website which explains (for the reject messages that you choose to document) what a sender needs to do to avoid being reject will do no harm when appended to reject messages that are already "self-documenting" or which you would choose to no explain further. The URL can explain that too. > The only rejects that I get calls or emails about are: > > reject_non_fqdn_helo_hostname, > reject_unknown_helo_hostname, > reject_unknown_client_hostname, > reject_unknown_reverse_client_hostname > > If these four rejects had individually configurable error text, it would > help a lot. There are surely more, and making the text context-specific is likely not a good cost/benefit trade-off. -- Viktor.
Re: Change error messages returned by Postfix
On 1/4/11 8:32 PM, pf at alt-ctrl-del.org wrote: The only rejects that I get calls or emails about are: reject_non_fqdn_helo_hostname, reject_unknown_helo_hostname, reject_unknown_client_hostname, Don't blindly use that. It causes a LOT of false positives. reject_unknown_reverse_client_hostname That's safer to use. If these four rejects had individually configurable error text, it would help a lot. Instead of Helo command rejected: Host not found, I could choose to return: Helo command rejected: Host not found; see example.tld?helo=somedomain.local What would that tell the sender *admin* that he didn't already know ? Note that information in SMTP logs and sessions is generally only read by, and therefore only useful to, system admins. -- J.
Re: Change error messages returned by Postfix
"Jeroen Geilman": On 1/4/11 8:32 PM, pf at alt-ctrl-del.org wrote: The only rejects that I get calls or emails about are: reject_non_fqdn_helo_hostname, reject_unknown_helo_hostname, reject_unknown_client_hostname, Don't blindly use that. It causes a LOT of false positives. reject_unknown_reverse_client_hostname That's safer to use. I only use the tougher ones against null senders and specific tlds, countries or IP ranges. If these four rejects had individually configurable error text, it would help a lot. Instead of Helo command rejected: Host not found, I could choose to return: Helo command rejected: Host not found; see example.tld?helo=somedomain.local What would that tell the sender *admin* that he didn't already know ? Note that information in SMTP logs and sessions is generally only read by, and therefore only useful to, system admins. I'm guessing that if the remote admin knew, we wouldn't have a problem... The reject text is often also included in the delivery status notification that gets returned to the sender. I'm trying to stop the chain of: Sender calls recipient, recipient calls their tech, recipient's tech calls me... Then I tell them to contact the sender's admin... Then the sender's admin claims that "everyone" else accepts their email, even though they don't have any reverse dns, and suggests that I add an exception for their servers. I would hope that occasionally someone in that chain would notice the url and read it, saving everyone else's time. I rarely get "why are you blocking me?" for rbl listed domains, so I'm guessing that those client specific self service urls do provide some benefit.
Re: Change error messages returned by Postfix
Wietse Venema: > > > So this would change the feature to: > > > > > > smtpd_reject_contact_information = > > > For assistance, call 800-555-0101 (pid=$pid, client=$client_addr) > > > > > > The result would look like: > > > > > > 554-5.5.1 : Recipient address reject: User unknown > > > 554 5.5.1 For assistance, call 800-555-0101 (pid=7283, > > > client=192.168.1.248) > > > > > > The helpdesk person then looks for "[7283]" and "192.168.1.248" in > > > the maillog file. This would lift some, but not all, of the mystery > > > with commands that Postfix rejects (syntax, etc.) without logging > > > them. ... > PID logging isn't useful with postscreen(8) because there is only > one process, so I'll add a localtime attribute. The rfc822_date > string seems too long to be useful; we need something that people > can use in a phone call. Having implemented $name expansion, I find that it is easy produce long contact footer text, so I have added multi-line support. Unfortunately, multi-line footers can be harder to read. For example, Postfix will word-wrap multi-line replies when it reports delivery errors in a bounce message. Suppose we have this nice multi-line contact footer: 554-5.5.1 : Recipient address rejected: User unknown 554-5.5.1 For assistance, call 800-555-0101. Please mention the 554-5.5.1 following information in your problem report: 554 5.5.1 localtime=Jan 4 15:42:00, client=192.168.1.248 The logging would look something horrible like: Jan 4 15:42:00 client postfix/smtp[25100]: B32E0924782: to=, relay=mail.example[192.168.1.58]:25, delay=0.04, delays=0.01/0/0.01/0.01, dsn=5.1.1, status=bounced (host mail.example[192.168.1.58] said: 550 554-5.5.1 : Recipient address rejected: User unknown 554-5.5.1 For assistance, call 800-555-0101. Please mention the 554-5.5.1 following information in your problem report: 554 5.5.1 localtime=Jan 4 15:42:00, client=192.168.1.248 The bounce message would look like: : host mail.example[192.168.1.58] said: 554-5.5.1 : Recipient address rejected: User unknown 554-5.5.1 For assistance, call 800-555-0101. Please mention the 554-5.5.1 following information in your problem report: 554 5.5.1 localtime=Jan 4 15:42:00, client=192.168.1.248 Final-Recipient: rfc822; u...@example Original-Recipient: rfc822; u...@example Action: failed Status: 5.1.1 Remote-MTA: dns; mail.example Diagnostic-Code: smtp; 554-5.5.1 : Recipient address rejected: User unknown 554-5.5.1 For assistance, call 800-555-0101. Please mention the 554-5.5.1 following information in your problem report: 554 5.5.1 localtime=Jan 4 15:42:00, client=192.168.1.248 On the other hand with a single-line contact footer, there would be no ugly "554-5.5.1" strings messing up the contact footer text: Server response: 554-5.5.1 : Recipient address rejected: User unknown 554 5.5.1 For assistance, call 800-555-0101. Please mention the following information in your problem report: localtime=Jan 4 15:42:00, client=192.168.1.248 The logging remains more readable: Jan 4 15:42:00 client postfix/smtp[25100]: B32E0924782: to=, relay=mail.example[192.168.1.58]:25, delay=0.04, delays=0.01/0/0.01/0.01, dsn=5.1.1, status=bounced (host mail.example[192.168.1.58] said: 550 554-5.5.1 : Recipient address rejected: User unknown 554-5.5.1 For assistance, call 800-555-0101. Please mention the following information in your problem report: localtime=Jan 4 15:42:00, client=192.168.1.248 As does the bounce message text: : host mail.example[192.168.1.58] said: 554-5.5.1 : Recipient address rejected: User unknown 554 5.1.1 For assistance, call 800-555-0101. Please mention the following information in your problem report: localtime=Jan 4 15:42:00, client=192.168.1.248 Final-Recipient: rfc822; u...@example Original-Recipient: rfc822; u...@example Action: failed Status: 5.1.1 Remote-MTA: dns; mail.example Diagnostic-Code: smtp; 554-5.5.1 : Recipient address rejected: User unknown 554 5.1.1 For assistance, call 800-555-0101. Please mention the following information in your problem report: localtime=Jan 4 15:42:00, client=192.168.1.248 Wietse
Re: Change error messages returned by Postfix
On 1/4/2011 3:04 PM, pf at alt-ctrl-del.org wrote: I'm trying to stop the chain of: Sender calls recipient, recipient calls their tech, recipient's tech calls me... Then I tell them to contact the sender's admin... Then the sender's admin claims that "everyone" else accepts their email, even though they don't have any reverse dns, and suggests that I add an exception for their servers. I would hope that occasionally someone in that chain would notice the url and read it, saving everyone else's time. I rarely get "why are you blocking me?" for rbl listed domains, so I'm guessing that those client specific self service urls do provide some benefit. There won't be reject-specific text anytime soon; the effort is just too high. Implementing custom text for just a few reject_* restrictions would raise false expectations, and is unlikely to be implemented judging from past half-solution proposals. A "generic" self-help web link that refers them to match the first part of the reject message with a list of possibilities should be sufficient. I believe this to be a fairly common practice already. -- Noel Jones
Re: Change error messages returned by Postfix
On 1/4/11 10:04 PM, pf at alt-ctrl-del.org wrote: I'm trying to stop the chain of: Sender calls recipient, recipient calls their tech, recipient's tech calls me... Then I tell them to contact the sender's admin... Then the sender's admin claims that "everyone" else accepts their email, even though they don't have any reverse dns, and suggests that I add an exception for their servers. While I certainly see and agree with your point, I hope you realize that that chain should have stopped with the sender admin reading his logs and admitting he knows why it is being rejected. HE's the one not doing a proper job as far as I am concerned. Also, both sender AND recipient admin not being you only occurs if you relay for $strangers. Not many people relay for $strangers anymore :) -- J.
Re: Change error messages returned by Postfix
On Tue, Jan 04, 2011 at 04:09:04PM -0500, Wietse Venema wrote: > Having implemented $name expansion, I find that it is easy produce > long contact footer text, so I have added multi-line support. > > Unfortunately, multi-line footers can be harder to read. For example, > Postfix will word-wrap multi-line replies when it reports delivery > errors in a bounce message. > > Suppose we have this nice multi-line contact footer: > > 554-5.5.1 : Recipient address rejected: User unknown > 554-5.5.1 For assistance, call 800-555-0101. Please mention the > 554-5.5.1 following information in your problem report: > 554 5.5.1 localtime=Jan 4 15:42:00, client=192.168.1.248 When the Postfix SMTP client consumes the multiple-lines of a multi-line response, it should I think drop all but the first occurence of the XYZ-A.B.C codes, making the two forms indistiguishable. > The logging would look something horrible like: > > Jan 4 15:42:00 client postfix/smtp[25100]: B32E0924782: > to=, relay=mail.example[192.168.1.58]:25, > delay=0.04, delays=0.01/0/0.01/0.01, dsn=5.1.1, status=bounced > (host mail.example[192.168.1.58] said: 550 554-5.5.1 : > Recipient address rejected: User unknown 554-5.5.1 For assistance, > call 800-555-0101. Please mention the 554-5.5.1 following > information in your problem report: 554 5.5.1 localtime=Jan 4 > 15:42:00, client=192.168.1.248 Per the above this issue already applies when the remote server is not Postfix, and the fix is IMHO to prune the codes from the interior of the response. > > : host mail.example[192.168.1.58] said: 554-5.5.1 > : Recipient address rejected: User unknown 554-5.5.1 For > assistance, call 800-555-0101. Please mention the 554-5.5.1 following > information in your problem report: 554 5.5.1 localtime=Jan 4 15:42:00, > client=192.168.1.248 Which solves the issue for bounces. > On the other hand with a single-line contact footer, there would > be no ugly "554-5.5.1" strings messing up the contact footer text: > Agreed, and since, we don't control all potential SMTP servers that may generate a multi-line reply, we should perhaps deal with it on the client side... Here is a bounce in my queue trying to return to a Gmail-hosted spammer: 8A12750421C 1678 Sun Jan 2 10:55:26 MAILER-DAEMON (host ALT1.ASPMX.L.GOOGLE.com[74.125.77.27] said: 450-4.2.1 The user you are trying to contact is receiving mail at a rate that 450-4.2.1 prevents additional messages from being delivered. Please resend your 450-4.2.1 message at a later time. If the user is able to receive mail at that 450-4.2.1 time, your message will be delivered. For more information, please 450 4.2.1 visit http://mail.google.com/support/bin/answer.py?answer=6592 v45si53059220eeh.66 (in reply to RCPT TO command)) -- Viktor.
Re: Why use EGD instead of /dev/urandom in tls_random_source?
On 27/12/2010 17:01, Victor Duchovni wrote: So why would you change the tls_random_source to use EGD instead of /dev/urandom? You wouldn't, if you have a /dev/urandom, use it. and if you are short of entropy on a busy server then grab one (or more) of these: http://www.entropykey.co.uk/ I have a couple now (I have several machines compiled with "hardened" pax and that depletes entropy extremely quickly) and they are very simple to install and extremely cheap. I believe they are even fast enough that you can buy fewer than you have servers and distribute the entropy using the EGD protocol (helpful for virtualised server pools) (No relationship other than happy customer) Ed W
Re: Why use EGD instead of /dev/urandom in tls_random_source?
On Tue, Jan 04, 2011 at 10:42:09PM +, Ed W wrote: > I have a couple now (I have several machines compiled with "hardened" pax > and that depletes entropy extremely quickly) and they are very simple to > install and extremely cheap. I believe they are even fast enough that you > can buy fewer than you have servers and distribute the entropy using the > EGD protocol (helpful for virtualised server pools) Overkill for Postfix. The internal PRNG in OpenSSL plus tlsmgr retaining state across sessions, with only occasional seeding from /dev/urandom is more than sufficient for Postfix. Postfix does not "deplete" entropy. -- Viktor.
Re: unexpected filter response from SNFMilter when sending multiple messages to postfix over one SMTP connection
Alban Deniz: > Hi Wietse, > > A little over a year ago, you provided me with a patch to fix a postfix bug. > Now, one of the users of my milter (SNFMilter) is experiencing problems that > might be due to the bug. > > Could you please let me know which released version of postfix had the bug > fixed? The bug had something to do with the SMFIR_QUARANTINE implementation. > I couldn't find any info on this on http://www.postfix.org. > Perhaps you could refer me to a URL that has information on which > version of postfix has this bug > fixed. It is the first webpage that comes up when I google for your name! Query: site:postfix.org Alban Deniz Below is a copy of the text. Good luck getting the Linux distros to upgrade. Many take security patches only, and such patches are very rare with Postfix. Wietse Postfix stable release 2.6.5 An on-line version of this announcement is available at http://www.postfix.org/announcements/postfix-2.6.5.html The stable release Postfix 2.6.5 addresses the defects described below (some already addressed with the not-announced Postfix 2.6.3 release). These defects are also addressed in the legacy releases that are still maintained: Postfix 2.5.9, 2.4.13 and 2.3.19. Do not use Postfix 2.6.4, 2.5.8, 2.4.12, 2.3.18, 2.7-20090807, and 2.7-20090807-nonprod. These contain a DNS workaround that causes more trouble than it prevents. It is removed until further notice. Defects fixed with Postfix 2.6.3: * The Postfix Milter client got out of step with a Milter application after the application sent a "quarantine" request at end-of-message time. The Milter application would still be in the end-of-message state, while Postfix would already be working on the next SMTP event, typically, QUIT or MAIL FROM. In the latter case, Milter responses for the previously-received email message would be applied towards the next MAIL FROM transaction. This problem was diagnosed with help from Alban Deniz. Defects fixed with Postfix 2.6.5: * The Postfix SMTP server would abort with an "unexpected lookup table" error when an SMTPD policy server was mis-configured in a particular way. The source code is available from ftp://ftp.porcupine.org/mirrors/postfix-release/index.html and from the mirrors listed at http://www.postfix.org/download.html.
