Bounce tracking
Hi,
I'm trying to set up simple bounce handling in Postfix. I was hoping not to
need/want VERP, but simply trying to get Postfix to call a script with the
failed (bounced/delayed) RCPT TO address, instead of sending a bounce e-mail
with that bounced address in the body. (Current version is 3.1.0-3ubuntu0.3,
from Ubuntu 16.04).
So far, I've tried:
main.cf:
notify_classes = bounce
bounce_notice_recipient = bouncehand...@example.com
transport_maps = hash:/etc/postfix/transport_maps
master.cf:
bouncehandler unix - n n - - pipe
flags=FRq user=bouncehandler argv=/usr/local/bin/postfix-bounce-handler.sh
--sender ${sender} --recipient ${recipient}
transport_maps:
bouncehand...@example.com bouncehandler:
/usr/local/bin/postfix-bounce-handler.sh
#!/bin/bash
debug_file="/tmp/bouncelog.txt"
datestamp=$(date +%Y%m%d-%H:%M)
echo "[$datestamp] $@" >> "$debug_file"
But, the only output I seem to get, is from the double bounce, and not the
bounced address:
[20181130-17:43] --sender double-bou...@mailserver.example.com --recipient
bouncehand...@example.com
Postfix knows exactly which address failed, because it includes it in the mail
body of bounce notices:
: host ASPMX.L.GOOGLE.COM[2a00:1450:4013:c00::1b] said:
550-5.1.1
The email account that you tried to reach does not exist. Please try
550-5.1.1 double-checking the recipient's email address for typos or
550-5.1.1 unnecessary spaces. Learn more at 550 5.1.1
https://support.google.com/mail/?p=NoSuchUser a12si2525633edk.106 - gsmtp
(in reply to RCPT TO command)
So instead of sending that e-mail, can I call the script with that address?
Or, am I going to have to parse that message (that comes in on std-in)?
Regards,
Wiebe
Re: Relaying e-mail from the bash command line (with sendmail probably)
- Original Message - From: Wietse Venema wie...@porcupine.org To: Wiebe Cazemier wi...@halfgaar.net Cc: Postfix users postfix-users@postfix.org Sent: Sunday, 17 June, 2012 2:41:29 AM Subject: Re: Relaying e-mail from the bash command line (with sendmail probably) Wiebe Cazemier: Transport maps can be per-recipient. But when I want to relay to another server, I don't want to send it to one recipient. I want to send it to whatever recipient the original message was sent to, but to another server. transport_maps changes the relay HOST, but NOT the RECIPIENT. Wietse But, my problem is this: - host a.com receives mail for j...@a.com. - after being queued, it goes through content_filter. - content filter script needs to send to another host, and therefore I define a transport map: @a.com smtp:[b.com] and I just use sendmail -G -i -f sender -- recipient message. - mail cannot be delivered locally anymore, because the message fed back into postfix that should be delivered locally, is also match by the transport map and will be sent to b.com as well. Am I missing something here?
Re: Relaying e-mail from the bash command line (with sendmail probably)
- Original Message - From: Jeroen Geilman jer...@adaptr.nl To: postfix-users@postfix.org Sent: Sunday, 17 June, 2012 11:15:51 AM Subject: Re: Relaying e-mail from the bash command line (with sendmail probably) Use the content_filter to directly relay to the destination host ? I would love to. How :)? I can do: content_filter=smtp:[b.com] but, then the original message isn't fed back into postfix and the original machine (a.com) has no message data anymore. That's why I wanted to use the bash script, so that I can echo the message back out onto stdout. Or am I mistaken?
Relaying e-mail from the bash command line (with sendmail probably)
Hi, In a bash script, I have: - an e-mail message with full headers in a tmp file. - A from address (to use for -f with 'sendmail') - a recipient (u...@example.com). How do I relay this message to another server than example.com, but do set RCPT TO to u...@example.com when relaying to that other server? One option I can think of is using a transport entry in transport maps, but because this runs on the server example.com, I can't set another transport for example.com. Any advice is welcome. Regards, Wiebe
Re: Relaying e-mail from the bash command line (with sendmail probably)
- Original Message - From: Wietse Venema wie...@porcupine.org To: Postfix users postfix-users@postfix.org Sent: Saturday, 16 June, 2012 3:50:40 PM Subject: Re: Relaying e-mail from the bash command line (with sendmail probably) Transport maps can be per-recipient. But when I want to relay to another server, I don't want to send it to one recipient. I want to send it to whatever recipient the original message was sent to, but to another server. If that does not answer the question, please describe the problem that you are trying to solve (some u...@example.com needs special processing before it can be delivered to the example.com server) instead of the solution (deliver one specific u...@example.com to a different server without creating a mail delivery loop). It's an implementation detail for another problem I asked some days ago: delivering mail locally and relaying to another server. bcc-ing was suggested with bcc_maps, but it doesn't work for me, because it doesn't produce a correct X-Original-To: and Delivered-To: header. I got stuck trying to use bcc maps, so that's why I'm trying to implement a postfix tee. See this for what I did: http://serverfault.com/a/399179/31475 I just want Postfix to deliver normally and then use content_filter to pass the message to a batch script which relays it to another server.
Re: Sending mail to custom transport and second server
- Original Message - From: Jeroen Geilman jer...@adaptr.nl To: postfix-users@postfix.org Sent: Tuesday, 5 June, 2012 7:51:47 PM Subject: Re: Sending mail to custom transport and second server recipient_bcc_maps = hash:/etc/postfix/backup_domains, with the following content: @example.netcatch...@second.postfix.box Depending on your specific setup, there may be much better solutions, but this is what you asked for verbatim. Actually, this is not really what I meant. This BCCs everything to one e-mail address. What I would like, is to have a transport with two nexthops, so to speak. I need the primary server to deliver to its zarafa transport as well as relay to the secondary server. The secondary server then knows to which address it was sent and places the X-Original-To and Delivered-To.
Re: Sending mail to custom transport and second server
- Original Message - From: Jeroen Geilman jer...@adaptr.nl To: postfix-users@postfix.org Sent: Tuesday, 5 June, 2012 7:51:47 PM Subject: Re: Sending mail to custom transport and second server recipient_bcc_maps = hash:/etc/postfix/backup_domains, with the following content: @example.netcatch...@second.postfix.box Depending on your specific setup, there may be much better solutions, but this is what you asked for verbatim. I'll look into it when I'm back at work tomorrow. However, I'm all for better solutions. The way Postfix receives and delivers is basically made clear; it receives because example.net is mydestination, so it considers it to be local, and then it delivers using the zarafa transport. Any alternatives for setting up a machine that acts as real-time backup are welcome.
Re: unverified_recipient_tempfail_action = permit
- Original Message - From: Reindl Harald h.rei...@thelounge.net To: postfix-users@postfix.org Sent: Saturday, 11 June, 2011 6:23:59 PM Subject: Re: unverified_recipient_tempfail_action = permit Am 11.06.2011 16:55, schrieb Wiebe Cazemier: That's not what I meant. I meant that 99% of the time, the primary server will be up and recipient address verification will work to reject (spam) messages to unknown users. Those two scenario's you mentioned are when the primary is down or otherwise deferring. And those cases happen 1% of the time (figure meant to be illustrative). so you do not need any backup-MX because if your primary is not available the edferring happens on the sender this is teh way smtp works Default defer time for most SMTP servers is only 3 to 5 days, that is not long enough for me. So if you would accept mail when the primary is down, you may very briefly create backscatter, but it allows you to operate a backup MX server without syncing recipient maps, or have any other knowledge about it nut the backup-mx is really useless if it depends on the primary one for proper working and in the reality a backup-mx is useless, really I kind of disagree. It doesn't rely on the primary for proper functioning, it just makes use of knowledge of the primary when it can. only if you have some database-driven configuration with a replications salve on the backup-mx it makes any sense because your configuration is independent, if you are using a spam-filtering appliance as example the backup-mx is the dead of your spam-filtering and if you are using greylsiting the backup-mx is also the dead of well working service becasue if the primary mx ansers with temporary problem the sending server will try your backup-mx and if both of them doing greylist you are playing something like ping-pong with the senders without any sync between the servers
Re: unverified_recipient_tempfail_action = permit
- Original Message - From: Reindl Harald h.rei...@thelounge.net To: postfix-users@postfix.org Sent: Sunday, 12 June, 2011 10:04:02 AM Subject: Re: unverified_recipient_tempfail_action = permit Am 12.06.2011 09:06, schrieb Wiebe Cazemier: so you do not need any backup-MX because if your primary is not available the deferring happens on the sender this is the way smtp works Default defer time for most SMTP servers is only 3 to 5 days, that is not long enough for me. jokingly if you are longer than 3 times down with your primary MX you should consider outsourving you mailservices! Well, I also have some private servers and if I'm on vacation, I have a hard time fixing broken hardware. At this time, I have no cloud platform or other redundant platform in place. Plus, people sending me mail will get a defer notice. I'd rather prevent that. really - in the last ten years our longest outage of the mailserver was 10 hours bcause a hardware-failure, so why does it bother me how long is the defer time out there and if our server si longer than 5 days down my smallest problem are a hand of mails bouncing back to the sender So if you would accept mail when the primary is down, you may very briefly create backscatter, but it allows you to operate a backup MX server without syncing recipient maps, or have any other knowledge about it nut the backup-mx is really useless if it depends on the primary one for proper working and in the reality a backup-mx is useless, really I kind of disagree. It doesn't rely on the primary for proper functioning, it just makes use of knowledge of the primary when it can. IT DOES normally the backup-mx will get no messages as long as the primary is available so there are no valid/ivalid RCPT cached That is in a world where there is no spam. In a world where there is no spam, I don't need recipient address verification to reject mail on the backup to begin with. So when the primary is down, all is well. The only reason I do need recipient address verification is spam. And having the abused backup MX verify at the primary side, for me, is a good enough way to prevent backscatter. if your primary si down your backup-mx does know nothing and is a backscatter so cinfigure your mailservices properly or consider outsourcing them to anybody who can do this and makes a service level agreement where your mx is not down for some days I understand your point of view, but I think it should be possible to configure a MX server as backup for anyone who wants to use it, without maintaining extra address information, at the cost of creating backscatter when the primary is down (which can partly be avoided by installing good spam filtering).
Re: unverified_recipient_tempfail_action = permit
- Original Message - From: Wietse Venema wie...@porcupine.org To: Wiebe Cazemier wi...@halfgaar.net Cc: postfix-users@postfix.org Sent: Friday, 10 June, 2011 9:37:39 PM Subject: Re: unverified_recipient_tempfail_action = permit Wiebe Cazemier: That's why I was asking if it wouldn't be a good idea to have 'permit' be a viable option for unverified_recipient_tempfail_action. unverified_recipient_tempfail_action is triggered when: - The backup MX could not reach the primary MX. - The primary MX replied with a 4xx response. In both cases, the backup MX will not know if the recipient address is valid. That way, you will not create spam-induced backscatter 99% of the time and still function as a proper backup MX. No, in both cases, the backup MX will not know if the recipient address is valid. Therefore, accepting the email can result in backscatter. Your 99% number contradicts current measurements that indicate that most mail is spam. Wietse (sorry, misreplied. Replied to the list now) That's not what I meant. I meant that 99% of the time, the primary server will be up and recipient address verification will work to reject (spam) messages to unknown users. Those two scenario's you mentioned are when the primary is down or otherwise deferring. And those cases happen 1% of the time (figure meant to be illustrative). So if you would accept mail when the primary is down, you may very briefly create backscatter, but it allows you to operate a backup MX server without syncing recipient maps, or have any other knowledge about it.
Re: unverified_recipient_tempfail_action = permit
- Original Message - From: Wietse Venema wie...@porcupine.org To: Wiebe Cazemier wi...@halfgaar.net Cc: postfix-users@postfix.org Sent: Friday, 10 June, 2011 2:50:34 PM Subject: Re: unverified_recipient_tempfail_action = permit Wiebe Cazemier: - The server is backup MX for mail hosts that I don't know anything about. In that case, the backup MX needs to ask the primary MX if the recipient is valid. Otherwise, you become a backscatter source. Wietse But how can it do that when the primary server is down and while not deferring the incoming request?
Re: unverified_recipient_tempfail_action = permit
- Original Message - From: Victor Duchovni victor.ducho...@morganstanley.com To: Wiebe Cazemier wi...@halfgaar.net Cc: postfix-users@postfix.org Sent: Friday, 10 June, 2011 5:04:09 PM Subject: Re: unverified_recipient_tempfail_action = permit On Fri, Jun 10, 2011 at 05:00:16PM +0200, Wiebe Cazemier wrote: - Original Message - From: Wietse Venema wie...@porcupine.org To: Wiebe Cazemier wi...@halfgaar.net Cc: postfix-users@postfix.org Sent: Friday, 10 June, 2011 2:50:34 PM Subject: Re: unverified_recipient_tempfail_action = permit Wiebe Cazemier: - The server is backup MX for mail hosts that I don't know anything about. In that case, the backup MX needs to ask the primary MX if the recipient is valid. Otherwise, you become a backscatter source. Wietse But how can it do that when the primary server is down and while not deferring the incoming request? It can't. Never before seen recipients will be deferred, recipients validated while the primary MX was up and cached (for 7-14 days) will however be accepted. This is good enough, and the best you can do without getting a recipient feed from the primary MX host. Not considering spam, a backup MX cannot know any user on the primary MX, ever, because the only time it will try to verify the recipient address is when the primary is down. Otherwise mail won't be sent to it. And even with spam, then it can happen that the primary will go down 1 minute after or before the cache expires and it will have forgotten about the verified recipient. That's why I was asking if it wouldn't be a good idea to have 'permit' be a viable option for unverified_recipient_tempfail_action. That way, you will not create spam-induced backscatter 99% of the time and still function as a proper backup MX.
unverified_recipient_tempfail_action = permit
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
Re: unverified_recipient_tempfail_action = permit
Well, when the primar is down, all incoming messages on the fallback are deferred, because it can't do the verification. This means the result is the same as having no fallback at all. Ansgar Wiechers li...@planetcobalt.net wrote: On 2011-06-09 Wiebe Cazemier wrote: 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. Why? What issue in particular do you see with simply doing recipient verification (and rejection of messages to invalid recipients) on bot MXs? Regards Ansgar Wiechers -- Abstractions save us time working, but they don't save us time learning. --Joel Spolsky
