Long term storage of undeliverable mail
in [Postfix]
|
Prev: what is the quickest way to bounce all message in the defer queue?
Next: Block/allow incoming IP only for SOME domains
From: Mark Goodge on 23 Jul 2010 03:32 OK, I'm sure this is in the documentation somewhere, but my brain isn't working this morning and I need to get a fix for this fairly quickly, so I'm asking here instead :-) Anyway, I currently have a situation where mail is currently received by machine A, which then forwards it to machine B. (B is inside a firewall, A is the public-facing mail server and is the only external system which has access to B on port 25). Last night, the internal network on which B resides suffered a catastrophic failure and B is, therefore, not accepting mail from A. It's likely that it won't be accepting mail again until after the weekend. What I need to do is configure A so that mail destined for B is stored indefinitely (well, for a few days, at least) without generating NDRs or attempted delivery notifications, so that when B comes back online all the stored mail can be delivered and none of the senders will have received any bounces or delay notifications. So my question is: which parameters do I need to change, and what should their values be, to achieve this? I'm currently using Postfix 2.3.8, and here's my postconf -n with some private data redacted: alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases append_dot_mydomain = no biff = no broken_sasl_auth_clients = yes config_directory = /etc/postfix header_checks = pcre:/etc/postfix/header_checks home_mailbox = Maildir/ inet_interfaces = all mailbox_size_limit = 0 message_size_limit = 30480000 mydestination = $myhostname , [redacted] myhostname = [redacted] mynetworks = 127.0.0.0/8,[redacted] myorigin = /etc/mailname recipient_delimiter = + smtpd_banner = $myhostname ESMTP $mail_name here - who the heck are you? smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination reject_non_fqdn_sender reject_non_fqdn_helo_hostname check_sender_access hash:/etc/postfix/sender_access smtpd_sasl_path = smtpd virtual_alias_domains = mysql:/etc/postfix/mysql_domains.cf virtual_alias_maps = mysql:/etc/postfix/mysql_aliases.cf Thanks Mark -- http://mark.goodge.co.uk
From: Wietse Venema on 23 Jul 2010 08:37 Mark Goodge: > OK, I'm sure this is in the documentation somewhere, but my brain isn't > working this morning and I need to get a fix for this fairly quickly, so > I'm asking here instead :-) > > Anyway, I currently have a situation where mail is currently received by > machine A, which then forwards it to machine B. (B is inside a firewall, > A is the public-facing mail server and is the only external system which > has access to B on port 25). Last night, the internal network on which B > resides suffered a catastrophic failure and B is, therefore, not > accepting mail from A. It's likely that it won't be accepting mail again > until after the weekend. > > What I need to do is configure A so that mail destined for B is stored > indefinitely (well, for a few days, at least) without generating NDRs or > attempted delivery notifications, so that when B comes back online all > the stored mail can be delivered and none of the senders will have > received any bounces or delay notifications. Consider temporarily increasing the bounce_queue_lifetime and maximal_queue_lifetime. This requires "postfix reload" as the life times are implemented in the queue manager which normally runs forever. Wietse
From: Mark Goodge on 23 Jul 2010 08:57
On 23/07/2010 13:37, Wietse Venema wrote: > Mark Goodge: >> >> What I need to do is configure A so that mail destined for B is stored >> indefinitely (well, for a few days, at least) without generating NDRs or >> attempted delivery notifications, so that when B comes back online all >> the stored mail can be delivered and none of the senders will have >> received any bounces or delay notifications. > > Consider temporarily increasing the bounce_queue_lifetime and > maximal_queue_lifetime. > > This requires "postfix reload" as the life times are implemented > in the queue manager which normally runs forever. Thanks. That looks to be precisely what I need. In fact, the defaults should be OK, since we should have the internal server accepting mail again within 5 days, but it's worth noting this in case that turns out not to be achievable. Mark -- http://mark.goodge.co.uk |