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: "Jeroen Geilman" > 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?
Re: Relaying e-mail from the bash command line (with sendmail probably)
- Original Message - > From: "Wietse Venema" > To: "Wiebe Cazemier" > Cc: "Postfix users" > 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: "Wietse Venema" > To: "Postfix users" > 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.
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: Sending mail to custom transport and second server
- Original Message - > From: "Jeroen Geilman" > 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" > 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.
Sending mail to custom transport and second server
Hi,
I have a Zarafa server that uses Postfix for local delivery. I want it to send
e-mail (sent do one specific domain) to a second server as last-resort backup
(there already are nightly backups). I have the second Postfix server already
setup to consider itself the target for the domain in question. It delivers in
one catch-all box with X-Original-To and Delivered-To headers, so that I can
use fetchmail to read the messages and redeliver to the Delivered-To.
What's left, is having the primary deliver to it's mailbox_transport AND
forward to that second server.
Postfix delivers mail to Zarafa like:
mailbox_transport = zarafa: zarafa_destination_recipient_limit = 1
virtual_alias_maps = mysql:/etc/postfix/mysql-aliases.cf
The mailbox transport (as defined in master.cf) is a tool that accepts data on
stdin to deliver into Zarafa's store (mysql + file based). Virtual_alias_maps
is an SQL command which basically returns the j.doe in j@example.com, but
only for existing users. In other words, it retrieves the Zarafa username from
the e-mail address.
>From master.cf:
zarafa unix - n n - 10 pipe
flags= user=vmail argv=/usr/bin/zarafa-dagent ${user}
How do I setup Postfix so that it sends all incoming mail (for one domain only)
to that zarafa transport as well as forward to another server?
Regards,
Wiebe
Re: unverified_recipient_tempfail_action = permit
- Original Message - > From: "Reindl Harald" > 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: "Reindl Harald" > 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: "Wietse Venema" > To: "Wiebe Cazemier" > 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: "Victor Duchovni" > To: "Wiebe Cazemier" > 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" > > > To: "Wiebe Cazemier" > > > 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.
Re: unverified_recipient_tempfail_action = permit
- Original Message - > From: "Wietse Venema" > To: "Wiebe Cazemier" > 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: "Ansgar Wiechers" > To: postfix-users@postfix.org > Sent: Friday, 10 June, 2011 12:47:35 AM > Subject: Re: unverified_recipient_tempfail_action = permit > > On 2011-06-10 Wiebe Cazemier wrote: > > Ansgar Wiechers 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? > > > > 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. > > There's more than one way to do recipient verification. Use > $relay_recipient_maps on the backup MX. And don't top-post. > > Regards > Ansgar Wiechers > Sorry, I forgot to mention. I can't use recipient maps because: - The server acts also as incoming mail handler for another machine which it relays to. That target machine has dynamically created addresses by users on a control panel. - The server is backup MX for mail hosts that I don't know anything about.
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 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
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
