Re: Deferred mail and transports and retries
Hi Wietse, This helps. Half reading is always bad. This clears everything about my doubt. One other thing still remains. I've multiple smtp services defined like this. (in master.cf, to use different IPs, selected randomly) ob-smtp1 unix- - n - - smtp -o smtp_bind_address=1.2.3.4 -o syslog_name=postfix-smtp1 ob-smtp2 unix- - n - - smtp -o smtp_bind_address=5.6.7.8 -o syslog_name=postfix-smtp2 I suppose that if a message delivered via one of the transport and deferred, it'll always be tried via the same smtp service. Is there a possibility where I can change the smtp service while retrying for a already deferred mail? On Thu, Jul 25, 2013 at 6:06 PM, Wietse Venema wie...@porcupine.org wrote: Abhijeet Rastogi: Hi Wietse, Thanks for you reply. I may be wrong but I just know what I read in http://tools.ietf.org/html/rfc5321#section-4.5.4 The sender MUST delay retrying a particular destination after one attempt has failed. In general, the retry interval SHOULD be at According to RFC 5321 section 5.1, the sending host should try at least two delivery addresses. Quote: When the lookup succeeds, the mapping can result in a list of alternative delivery addresses rather than a single address, because of multiple MX records, multihoming, or both. To provide reliable mail transmission, the SMTP client MUST be able to try (and retry) each of the relevant addresses in this list in order, until a delivery attempt succeeds. However, there MAY also be a configurable limit on the number of alternate addresses that can be tried. In any case, the SMTP client SHOULD try at least two addresses. If you believe that Postfix should wait between the attempts to connect to the first and the second MX address, then you are in error. Wietse -- Regards, Abhijeet Rastogi (shadyabhi) http://blog.abhijeetr.com
Re: Deferred mail and transports and retries
Abhijeet Rastogi: Hi Wietse, This helps. Half reading is always bad. This clears everything about my doubt. One other thing still remains. I've multiple smtp services defined like this. (in master.cf, to use different IPs, selected randomly) ob-smtp1 unix- - n - - smtp -o smtp_bind_address=1.2.3.4 -o syslog_name=postfix-smtp1 ob-smtp2 unix- - n - - smtp -o smtp_bind_address=5.6.7.8 -o syslog_name=postfix-smtp2 I suppose that if a message delivered via one of the transport and deferred, it'll always be tried via the same smtp service. Is there a possibility where I can change the smtp service while retrying for a already deferred mail? You can specify an alternate MTA (with smtp_fallback_relay) for delayed mail. There is no feature to specify an alternate delivery agent for delayed mail. The example looks like an attempt to circumvent Yahoo etc. rate limits per client IP address. I don't have to make that easy with Postfix. Wietse
Re: Deferred mail and transports and retries
You can specify an alternate MTA (with smtp_fallback_relay) for delayed mail. There is no feature to specify an alternate delivery agent for delayed mail. Hmm, I was aware of that thing. I've not used this feature but it's definitely worth trying. The example looks like an attempt to circumvent Yahoo etc. rate limits per client IP address. I don't have to make that easy with Postfix. It's not about me trying to do spam. I'm part of a hosting company and sometimes our IPs get blocked temporarily when our outbound spam system stops performing for some odd reason. Thanks for the help. Wietse -- Regards, Abhijeet Rastogi (shadyabhi) http://blog.abhijeetr.com
Deferred mail and transports and retries
Hi all, 1. If a mail is temporarily deferred from a remote MTA, postfix should back-off instantly for some time but I observed this today. Jul 24 06:40:16 server.name postfix-smtp4/smtp[6204]: DEC8B4F0185: host mta6.am0.yahoodns.net[98.138.112.35] refused to talk to me: 421 4.7.0 [GL01] Message from (1.2.3.4) temporarily deferred - 4.16.50. Please refer to http://postmaster.yahoo.com/errors/postmaster-21.html Jul 24 06:40:16 server.name postfix-smtp4/smtp[6204]: DEC8B4F0185: host mta6.am0.yahoodns.net[63.250.192.46] refused to talk to me: 421 4.7.0 [GL01] Message from (1.2.3.4) temporarily deferred - 4.16.50. Please refer to http://postmaster.yahoo.com/errors/postmaster-21.html Can anyone explain why would this happen? 2. I've multiple transports defined in master.cf which bind to different IPs. When a mail is deferred, will it always be tried via the same transport? If yes, is there a way I can change this behaviour? -- Regards, Abhijeet Rastogi (shadyabhi) http://blog.abhijeetr.com
Re: Deferred mail and transports and retries
On Thu, Jul 25, 2013 at 12:16:15PM +0530, Abhijeet Rastogi wrote: Hi all, 1. If a mail is temporarily deferred from a remote MTA, postfix should back-off instantly for some time but I observed this today. Jul 24 06:40:16 server.name postfix-smtp4/smtp[6204]: DEC8B4F0185: host mta6.am0.yahoodns.net[98.138.112.35] refused to talk to me: 421 4.7.0 [GL01] Message from (1.2.3.4) temporarily deferred - 4.16.50. Please refer to http://postmaster.yahoo.com/errors/postmaster-21.html Jul 24 06:40:16 server.name postfix-smtp4/smtp[6204]: DEC8B4F0185: host mta6.am0.yahoodns.net[63.250.192.46] refused to talk to me: 421 4.7.0 [GL01] Message from (1.2.3.4) temporarily deferred - 4.16.50. Please refer to http://postmaster.yahoo.com/errors/postmaster-21.html Can anyone explain why would this happen? It's kind of explained in http://postmaster.yahoo.com/errors/postmaster-21.html (and Links from there) You get this, because there were complaints of Yahoo!-Users, that they don't want some of the mails your mailserver sends. Michael 2. I've multiple transports defined in master.cf which bind to different IPs. When a mail is deferred, will it always be tried via the same transport? If yes, is there a way I can change this behaviour? -- Regards, Abhijeet Rastogi (shadyabhi) http://blog.abhijeetr.com -- Michael P. Demelbauer Systemadministration WSR Arsenal, Objekt 20 1030 Wien --- To learn something new, take the path that you took yesterday. --John Burroughs
Re: Deferred mail and transports and retries
Hi Micheal, Thanks for your reply. Actually, the issue was I was just writing the mail and it got Sent by mistake. (But, then reading the mail I thought that the message was conveyed.) The issue is, why does postfix retry the second time instantly (within 1 sec)? Shouldn't postfix wait till the next deferred queue scan happens? (I'm talking about backoff time etc). It tries the delivery 2 times within 1 sec. My understanding says that it should wait till the minimum backoff time. On Thu, Jul 25, 2013 at 1:01 PM, Michael P. Demelbauer michael.demelba...@wsr.ac.at wrote: On Thu, Jul 25, 2013 at 12:16:15PM +0530, Abhijeet Rastogi wrote: Hi all, 1. If a mail is temporarily deferred from a remote MTA, postfix should back-off instantly for some time but I observed this today. Jul 24 06:40:16 server.name postfix-smtp4/smtp[6204]: DEC8B4F0185: host mta6.am0.yahoodns.net[98.138.112.35] refused to talk to me: 421 4.7.0 [GL01] Message from (1.2.3.4) temporarily deferred - 4.16.50. Please refer to http://postmaster.yahoo.com/errors/postmaster-21.html Jul 24 06:40:16 server.name postfix-smtp4/smtp[6204]: DEC8B4F0185: host mta6.am0.yahoodns.net[63.250.192.46] refused to talk to me: 421 4.7.0 [GL01] Message from (1.2.3.4) temporarily deferred - 4.16.50. Please refer to http://postmaster.yahoo.com/errors/postmaster-21.html Can anyone explain why would this happen? It's kind of explained in http://postmaster.yahoo.com/errors/postmaster-21.html (and Links from there) You get this, because there were complaints of Yahoo!-Users, that they don't want some of the mails your mailserver sends. Michael 2. I've multiple transports defined in master.cf which bind to different IPs. When a mail is deferred, will it always be tried via the same transport? If yes, is there a way I can change this behaviour? -- Regards, Abhijeet Rastogi (shadyabhi) http://blog.abhijeetr.com -- Michael P. Demelbauer Systemadministration WSR Arsenal, Objekt 20 1030 Wien --- To learn something new, take the path that you took yesterday. --John Burroughs -- Regards, Abhijeet Rastogi (shadyabhi) http://blog.abhijeetr.com
Re: Deferred mail and transports and retries
Abhijeet Rastogi: The issue is, why does postfix retry the second time instantly (within 1 sec)? Shouldn't postfix wait till the next deferred queue scan happens? No, this is not required. If you disagree, please point out in the SMTP standard, RTFM RFC 5321, where Postfix is in error. Wietse
Re: Deferred mail and transports and retries
Hi Wietse, Thanks for you reply. I may be wrong but I just know what I read in http://tools.ietf.org/html/rfc5321#section-4.5.4 The sender MUST delay retrying a particular destination after one attempt has failed. In general, the retry interval SHOULD be at least 30 minutes; however, more sophisticated and variable strategies will be beneficial when the SMTP client can determine the reason for non-delivery. Can you help me understand as to where I'm wrong? It says that after one attempt is made, it should delay the next retry. Is it like, all MXs (ip addresses) are tried in one go before actually deferring a mail? Thanks in advance. On Thu, Jul 25, 2013 at 3:54 PM, Wietse Venema wie...@porcupine.org wrote: Abhijeet Rastogi: The issue is, why does postfix retry the second time instantly (within 1 sec)? Shouldn't postfix wait till the next deferred queue scan happens? No, this is not required. If you disagree, please point out in the SMTP standard, RTFM RFC 5321, where Postfix is in error. Wietse -- Regards, Abhijeet Rastogi (shadyabhi) http://blog.abhijeetr.com
Re: Deferred mail and transports and retries
Abhijeet Rastogi: Hi Wietse, Thanks for you reply. I may be wrong but I just know what I read in http://tools.ietf.org/html/rfc5321#section-4.5.4 The sender MUST delay retrying a particular destination after one attempt has failed. In general, the retry interval SHOULD be at According to RFC 5321 section 5.1, the sending host should try at least two delivery addresses. Quote: When the lookup succeeds, the mapping can result in a list of alternative delivery addresses rather than a single address, because of multiple MX records, multihoming, or both. To provide reliable mail transmission, the SMTP client MUST be able to try (and retry) each of the relevant addresses in this list in order, until a delivery attempt succeeds. However, there MAY also be a configurable limit on the number of alternate addresses that can be tried. In any case, the SMTP client SHOULD try at least two addresses. If you believe that Postfix should wait between the attempts to connect to the first and the second MX address, then you are in error. Wietse
Re: Deferred mail and transports and retries
Am 25.07.2013 09:52, schrieb Abhijeet Rastogi: The issue is, why does postfix retry the second time instantly (within 1 sec)? Shouldn't postfix wait till the next deferred queue scan happens? Because that's best Postfix can do. Because Postfix SHOULD do that: *) Because if on MX is down, the second one could/should be up and running, so why shouldn't Postfix use it *) Because Postfix isn't interested in wasting resources and storing deliverable e-mails in the deferred queue *) Because the sender wants to have delivered his e-mail fast without unnecessary delays *) Because the recupient wants to receive his e-mails quickly without unnecessary delays If you believe that deferring e-mails and wasting time is helpful, then use smtp_mx_address_limit = 1 smtp_mx_session_limit = 1 but don't complain about delays. Peer -- Heinlein Support GmbH Schwedter Str. 8/9b, 10119 Berlin http://www.heinlein-support.de Tel: 030 / 405051-42 Fax: 030 / 405051-19 Zwangsangaben lt. §35a GmbHG: HRB 93818 B / Amtsgericht Berlin-Charlottenburg, Geschäftsführer: Peer Heinlein -- Sitz: Berlin
Re: Deferred mail
On 18 January 2013 21:14, Muzaffer to...@ozses.net wrote:
On 17 January 2013 08:55, Timo Röhling timo.roehl...@gmx.de wrote:
Am 17.01.2013 06:20, schrieb Muzaffer:
Jan 17 06:14:20 ommuse postfix/smtp[25504]: BC05AF629A:
to=sertacona...@gmail.com mailto:sertacona...@gmail.com,
relay=none,
delay=116212, delays=116107/0.02/105/0, dsn=4.4.1, status=deferred
(connect to alt4.gmail-smtp-in.l.google.com
http://alt4.gmail-smtp-in.l.google.com[74.125.141.26]:25: Connection
timed out)
The message indicates that your system is unable to connect to the
Google servers, suggesting a network problem or a system overload.
As you can see from the logs, I get deferred. What does it even mean and
how can I fix it?
Deferred means that Postfix encountered a non-fatal error condition and
resolves this by waiting some time before trying again. Mostly, this is
harmless and Postfix does the right thing by default. You may have a
problem if Postfix gives up eventually.
Hi,
To debug, I've taken these steps:
1- I did telnet 74.125.141.26 25, and I got a reply. I think that
eliminates the connection fault.
2- I did telnet mail.ommuse.com 25 (my own server), and sent outside
world an e-mail. Then I got the above error again.
3- Using mutt, I sent outside world an e-mail. Again, I got the above
error.
How can I further troubleshoot?
Here's my postconf -n:
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
allow_percent_hack = no
append_dot_mydomain = no
biff = no
broken_sasl_auth_clients = yes
config_directory = /etc/postfix
home_mailbox = Maildir/
mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME
mailbox_size_limit = 0
mydestination = localhost.$mydomain, localhost, $mydomain, ommuse.com
myhostname = ommuse.com
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128, 5.9.235.23/32
myorigin = /etc/mailname
readme_directory = no
recipient_delimiter = +
relay_domains = $mydomain
sender_bcc_maps = hash:/etc/postfix/bcc
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
smtpd_recipient_restrictions = permit_sasl_authenticated,
permit_mynetworks,reject_unauth_destination,
reject_non_fqdn_hostname,reject_non_fqdn_sender,
reject_non_fqdn_recipient,reject_unauth_pipelining,
reject_invalid_hostname,reject_rbl_client sbl.spamhaus.org,
reject_rbl_client xbl.spamhaus.org
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
smtpd_sasl_local_domain = $myhostname
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes
virtual_alias_domains = $virtual_alias_maps
virtual_alias_maps = hash:/etc/postfix/virtual
Regards,
Thanks to several people on Freenode #postfix, I solved this issue. The
problem was iptables blocking outbound mail.
Regards,
Re: Deferred mail
On 17 January 2013 08:55, Timo Röhling timo.roehl...@gmx.de wrote:
Am 17.01.2013 06:20, schrieb Muzaffer:
Jan 17 06:14:20 ommuse postfix/smtp[25504]: BC05AF629A:
to=sertacona...@gmail.com mailto:sertacona...@gmail.com, relay=none,
delay=116212, delays=116107/0.02/105/0, dsn=4.4.1, status=deferred
(connect to alt4.gmail-smtp-in.l.google.com
http://alt4.gmail-smtp-in.l.google.com[74.125.141.26]:25: Connection
timed out)
The message indicates that your system is unable to connect to the
Google servers, suggesting a network problem or a system overload.
As you can see from the logs, I get deferred. What does it even mean and
how can I fix it?
Deferred means that Postfix encountered a non-fatal error condition and
resolves this by waiting some time before trying again. Mostly, this is
harmless and Postfix does the right thing by default. You may have a
problem if Postfix gives up eventually.
Hi,
To debug, I've taken these steps:
1- I did telnet 74.125.141.26 25, and I got a reply. I think that
eliminates the connection fault.
2- I did telnet mail.ommuse.com 25 (my own server), and sent outside world
an e-mail. Then I got the above error again.
3- Using mutt, I sent outside world an e-mail. Again, I got the above error.
How can I further troubleshoot?
Here's my postconf -n:
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
allow_percent_hack = no
append_dot_mydomain = no
biff = no
broken_sasl_auth_clients = yes
config_directory = /etc/postfix
home_mailbox = Maildir/
mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME
mailbox_size_limit = 0
mydestination = localhost.$mydomain, localhost, $mydomain, ommuse.com
myhostname = ommuse.com
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128, 5.9.235.23/32
myorigin = /etc/mailname
readme_directory = no
recipient_delimiter = +
relay_domains = $mydomain
sender_bcc_maps = hash:/etc/postfix/bcc
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
smtpd_recipient_restrictions = permit_sasl_authenticated,
permit_mynetworks,reject_unauth_destination,
reject_non_fqdn_hostname,reject_non_fqdn_sender,
reject_non_fqdn_recipient,reject_unauth_pipelining,
reject_invalid_hostname,reject_rbl_client sbl.spamhaus.org,
reject_rbl_client xbl.spamhaus.org
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
smtpd_sasl_local_domain = $myhostname
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes
virtual_alias_domains = $virtual_alias_maps
virtual_alias_maps = hash:/etc/postfix/virtual
Regards,
Re: Deferred mail
Muzaffer: Hi, I fear I might have misconfigured. Here's my logs: Jan 17 06:14:20 ommuse postfix/smtp[25504]: BC05AF629A: to= x...@gmail.com, relay=none, delay=116212, delays=116107/0.02/105/0, dsn=4.4.1, status=deferred (connect to alt4.gmail-smtp-in.l.google.com[74.125.141.26]:25: Connection timed out) Another possibility is that your ISP does not allow its customers to make connections to port 25, as an anti-spam countermeasure. If this is your relayhost, try relayhost = [smtp.gmail.com]:587. Wietse
Disable deferred mail sender notification
I've searched but haven't found quite what I'm trying to do. I have found a couple of similar questions here but no answer to my problem. I have a dozen outbound Postfix mail servers (vers. 2.5.5-6.8 2.5.2) processing a relatively large amount of e-mail from a service account, which triggers greylisting from providers such as yahoo.com and txt.att.net. Our inbound server gets overwhelmed processing bounced mail notifications in addition to SPAM and regular inbound e-mail. I was asked to config the outbound mail servers to quit returning deferred message delivery notifications back to our mail server but I'm not really seeing way to do that. These are 4xx messages... usually 421. We still need to process undeliverable (5xx) messages. If I understand correctly, this is handled by the bounce application which is specified in the services section /etc/postfix/master.cf. The line that I believe would need to change is: defer unix - - n - 0 bounce If I understand Postfix, the bounce application will handle both the delivery status notification that I'm trying to suppress and re-queuing the message for later delivery. I don't see any documented options to allow it to re-queue without sending the notification, but I may be reading past it if one is available. I don't see any other mechanism to handle the re-queue without the delivery notification. Can anybody help? I do have and example of the postconf -d if you'd like to see the whole thing, or I could provide specific variables if that would be easier. TIA, Paul
Re: Disable deferred mail sender notification
Paul: I was asked to config the outbound mail servers to quit returning deferred message delivery notifications back to our mail server but I'm not really seeing way to do that. The simplest option is to set delay_warning_time=0. http://www.postfix.org/postconf.5.html#delay_warning_time Changing this takes effect only for new mail. Wietse
Re: Disable deferred mail sender notification
Wietse, thanks for the quick response, and a solution that looks like it might work. That wouldn't also suppress 5xx bounce notifications, would it? In order to be good e-mail citizens we have to capture those undeliverable addresses and remove them from our active mail database. I'm assuming that the line time after which the sender receives the message headers of mail that is still queued implies that hard bounces would be removed from the queue and we would still get the bounce notification. Thanks again for your help. Paul Paul: I was asked to config the outbound mail servers to quit returning deferred message delivery notifications back to our mail server but I'm not really seeing way to do that. The simplest option is to set delay_warning_time=0. http://www.postfix.org/postconf.5.html#delay_warning_time Changing this takes effect only for new mail. Wietse
Moving deferred mail to another server
Hi There, We have two postfix servers (postfix from debian lenny). Is there any way to move all deferred mail from one server to another? Thanks Simon
Re: Moving deferred mail to another server
On 11/14/2010 11:06 PM, Simon wrote: Hi There, We have two postfix servers (postfix from debian lenny). Is there any way to move all deferred mail from one server to another? On the one with the deferred mail, add relay_host = [name.or.ip.of.other.postfix] to main.cf, then run postfix reload and postsuper -r ALL The other postfix must already be configured to handle the queued mail properly; it's impossible to give advice on that because you haven't told us WHY. -- J.
deferred mail
Hello, I'm using two instances of postfix and lately I've been getting a lot of deferred email, any suggestions how to stop accepting email that can't be delivered. I do have local recipients table, server should not accept email that can't be deliver. Please help! host# perl check_outmail -Queue ID- --Size-- Arrival Time -Sender/Recipient--- CC858A1091 4664 Thu Jul 15 12:58:42 MAILER-DAEMON (connect to forum.ituin.org[69.43.160.175]:25: Connection refused) mavn...@forum.ituin.org 49735A109F 4663 Thu Jul 15 13:16:52 MAILER-DAEMON (host offworldventures.com[216.97.232.215] said: 451 Temporary local problem - please try later (in reply to RCPT TO command)) adow...@offworldventures.com -- 10 Kbytes in 2 Requests. Host# postconf -n local_recipient_maps = hash:/usr/local/etc/postfix/userdb, hash:/usr/local/etc/postfix/uservirt mail_owner = postfix mailq_path = /usr/local/bin/mailq manpage_directory = /usr/local/man message_size_limit = 5000 mydestination = example.com, example2.com, example3.com myhostname = host.example.com mynetworks = 127.0.0.0/8, myorigin = example.com newaliases_path = /usr/local/bin/newaliases queue_directory = /var/spool/postfix readme_directory = no relay_domains = hash:/usr/local/etc/postfix/relay_domains sample_directory = /usr/local/etc/postfix sendmail_path = /usr/local/sbin/sendmail setgid_group = maildrop smtpd_banner = host.example.com smtpd_error_sleep_time = 0 smtpd_helo_required = yes smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination,reject_invalid_hostname, reject_non_fqdn_sender,reject_non_fqdn_recipient, reject_unknown_sender_domain,reject_unknown_recipient_domain, smtpd_sender_restrictions = hash:/usr/local/etc/postfix/access unknown_address_reject_code = 554 unknown_client_reject_code = 554 unknown_hostname_reject_code = 554 unknown_local_recipient_reject_code = 550 unverified_recipient_reject_code = 550 unverified_sender_reject_code = 550
Re: deferred mail
On Thu, Jul 15, 2010 at 02:42:17PM -0700, motty.cruz wrote: Hello, I'm using two instances of postfix and lately I've been getting a lot of deferred email, any suggestions how to stop accepting email that can't be delivered. I do have local recipients table, server should not accept email that can't be deliver. Please help! host# perl check_outmail -Queue ID- --Size-- Arrival Time -Sender/Recipient--- CC858A1091 4664 Thu Jul 15 12:58:42 MAILER-DAEMON (connect to forum.ituin.org[69.43.160.175]:25: Connection refused) mavn...@forum.ituin.org 49735A109F 4663 Thu Jul 15 13:16:52 MAILER-DAEMON (host offworldventures.com[216.97.232.215] said: 451 Temporary local problem - please try later (in reply to RCPT TO command)) adow...@offworldventures.com -- 10 Kbytes in 2 Requests. Two deferred bounces is a lot??? You need to read the bounce messages (use postcat -q) to see what undeliverable mail failed, how it got to you and where it was found undeliverable). local_recipient_maps = hash:/usr/local/etc/postfix/userdb, hash:/usr/local/etc/postfix/uservirt This covers local(8) recipients for domains listed in $mydestination. mydestination = example.com, example2.com, example3.com relay_domains = hash:/usr/local/etc/postfix/relay_domains You also have relay_domains, but no relay_recipient_maps, so you are accepting bouncing invalid recipients in these domains. -- Viktor.
track down deferred mail reason
Hi, I have setup postfix as an mx backup using: relay_domains = betterthanbacon.com defer_transports = smtp Works ok, but upon browsing the log /var/log/mail.log, I have found the following entry: May 18 13:06:56 ks postfix/error[14135]: 781A83E1F9: to=eweivivuhi7...@blokowe. pl, relay=none, delay=0.14, delays=0.09/0.04/0/0.01, dsn=4.3.2, status=deferred (deferred transport) Does this mean my postfix server has accepted an email to eweivivuhi7...@blokowe.pl and is now waiting for delivery? I have tried to telnet to my postfix on port 25 using the rcpt to: command to the same email address, but I got a relay denied message. How do I track down and fix this problem so that postfix will only accept emails for relay_domains? Thanks!
Re: track down deferred mail reason
Juan Devas: Hi, I have setup postfix as an mx backup using: relay_domains = betterthanbacon.com defer_transports = smtp Works ok, but upon browsing the log /var/log/mail.log, I have found the following entry: May 18 13:06:56 ks postfix/error[14135]: 781A83E1F9: to=eweivivuhi7...@blokowe. pl, relay=none, delay=0.14, delays=0.09/0.04/0/0.01, dsn=4.3.2, status=deferred (deferred transport) Does this mean my postfix server has accepted an email to eweivivuhi7...@blokowe.pl and is now waiting for delivery? I have tried to telnet to my postfix on port 25 using the rcpt to: command to the same email address, but I got a relay denied message. How do I track down and fix this problem so that postfix will only accept emails for relay_domains? TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html Thank you for using Postfix.
Re: Re queue failed email from deferred mail
On 9/15/2009 8:02 AM, Vernon A. Fort wrote: I had an internal server problem which ended up with 1000 or so messages sitting in the mail queue with a HOP-COUNT exceeded. These are good emails so i need to find a way to remove most of the Received lines in the message header and re-queue (re-send) the email. I'm thinking of using postcat queueid to a temporary file - striping the Received lines as i write out the file. Then just resend the message. Are there any gotchas with this approach? Thanks Vernon This sounds like a bad idea... It's probably better to just let them bounce back to the sender. First you must find out why these have hop-count exceeded and fix the problem. Otherwise you'll just end up in the same place again. General procedure: postcat -q QUEUEID /tmp/file Find the envelope sender and recipient(s) stored in the queued file. Don't use the From: or To: headers. Strip the postfix envelope records from the tmp file. Resubmit with sendmail -i -f sender -- recip1 recip2 recip3 ... /tmp/file It's very important to use the envelop sender and recipient(s), not the addresses listed in the From: or To: or other headers. The envelop sender and recipient(s) are listed in the *** ENVELOPE RECORDS *** section of the queue file. Postfix 2.7 and later has new options for the postcat command that would make this a little easier. http://www.postfix.org/postcat.1.html -- Noel Jones
Re: Re queue failed email from deferred mail
Noel Jones wrote: On 9/15/2009 8:02 AM, Vernon A. Fort wrote: I had an internal server problem which ended up with 1000 or so messages sitting in the mail queue with a HOP-COUNT exceeded. These are good emails so i need to find a way to remove most of the Received lines in the message header and re-queue (re-send) the email. I'm thinking of using postcat queueid to a temporary file - striping the Received lines as i write out the file. Then just resend the message. Are there any gotchas with this approach? Thanks Vernon This sounds like a bad idea... It's probably better to just let them bounce back to the sender. First you must find out why these have hop-count exceeded and fix the problem. Otherwise you'll just end up in the same place again. General procedure: postcat -q QUEUEID /tmp/file Find the envelope sender and recipient(s) stored in the queued file. Don't use the From: or To: headers. Strip the postfix envelope records from the tmp file. Resubmit with sendmail -i -f sender -- recip1 recip2 recip3 ... /tmp/file It's very important to use the envelop sender and recipient(s), not the addresses listed in the From: or To: or other headers. The envelop sender and recipient(s) are listed in the *** ENVELOPE RECORDS *** section of the queue file. Postfix 2.7 and later has new options for the postcat command that would make this a little easier. http://www.postfix.org/postcat.1.html -- Noel Jones The mail loop/hop problem WAS/IS fix. Alot of these messages are notifications which are time consuming to get reproduced. I would prefer to strip the needed stuff from the header and re-send/queue. THANKS for the examples with the envelope - i was planning on using the to/from from the header. The envelope makes perfect since! Vernon
deferred mail -retry
hi all what's the default deferred mail retry time in postfix? can i change it? appreciate ur help
Re: deferred mail -retry
* K bharathan kbhara...@gmail.com: hi all what's the default deferred mail retry time in postfix? retry time for what? -- Ralf Hildebrandt Postfix - Einrichtung, Betrieb und Wartung Tel. +49 (0)30-450 570-155 http://www.computerbeschimpfung.de Standard Cyrus SASL behaviour. SASL developers don't believe in logging. Logging is for wimps, real men use their psychic abilities to find out what's going on.-- Liviu Daia
Re: deferred mail -retry
retrying time for attempting deliver the message On Tue, Jun 9, 2009 at 1:16 PM, Ralf Hildebrandt ralf.hildebra...@charite.de wrote: * K bharathan kbhara...@gmail.com: hi all what's the default deferred mail retry time in postfix? retry time for what? -- Ralf Hildebrandt Postfix - Einrichtung, Betrieb und Wartung Tel. +49 (0)30-450 570-155 http://www.computerbeschimpfung.de Standard Cyrus SASL behaviour. SASL developers don't believe in logging. Logging is for wimps, real men use their psychic abilities to find out what's going on.-- Liviu Daia
Re: deferred mail -retry
thanks On Tue, Jun 9, 2009 at 2:24 PM, Ralf Hildebrandt ralf.hildebra...@charite.de wrote: * K bharathan kbhara...@gmail.com: retrying time for attempting deliver the message I assume you're thinking of non-local delivery queue_run_delay = 300s maximal_backoff_time = 4000s minimal_backoff_time = 300s The queue is scanned every 300s, initial minimal backoff is 300s, maximum backoff is 4000s, with every unsuccessful retry the timespan between to attempts is increased. -- Ralf Hildebrandt Postfix - Einrichtung, Betrieb und Wartung Tel. +49 (0)30-450 570-155 http://www.computerbeschimpfung.de Windows is the answer, but only if the question was 'what is the intellectual equivalent of being a galley slave?'
Mail not delivered to local users: status=deferred (mail transport unavailable)
Hi All, I set up an after-queue content filter following the instructions on http://www.postfix.org/FILTER_README.html . Everything works fine except that mail directed to local users is deferred when it is re-injected to postfix after the content filter. However, virtual and remote addresses work. I have the trivial-rewrite, qmgr, local, and error daemons running with the -v switch. Here is a `grep id mail.log` for a re-injected mail: === postfix/smtpd[22439]: BA9452DA112C: client=localhost[127.0.0.1] postfix/cleanup[22435]: BA9452DA112C: message- id=20090329202930.dc9872da1...@mail.knmm.de postfix/qmgr[22419]: qmgr_active_feed: incoming/BA9452DA112C postfix/qmgr[22419]: qmgr_message_alloc: active BA9452DA112C postfix/qmgr[22419]: BA9452DA112C: recipient limit 5000 postfix/qmgr[22419]: BA9452DA112C: from=a...@mail.knmm.de, size=516, nrcpt=1 (queue active) postfix/qmgr[22419]: qmgr_peer_select: BA9452DA112C retry 4.3.0 mail transport unavailable (1 of 5) postfix/qmgr[22419]: qmgr_job_retire: BA9452DA112C postfix/qmgr[22419]: send attr queue_id = BA9452DA112C postfix/error[22442]: BA9452DA112C: to=a...@mail.knmm.de, relay=none, delay=0.17, delays=0.02/0.13/0/0.02, dsn=4.3.0, status=deferred (mail transport unavailable) postfix/qmgr[22419]: qmgr_active_done: BA9452DA112C postfix/qmgr[22419]: wakeup BA9452DA112C after 300 secs postfix/qmgr[22419]: qmgr_active_defer: defer BA9452DA112C postfix/qmgr[22419]: qmgr_job_free: BA9452DA112C local postfix/qmgr[22419]: qmgr_job_free: BA9452DA112C retry === Here is my master.cf section for the re-injection smtpd: === 127.0.0.1:10025 inetn - y - - smtpd -o content_filter= -o local_recipient_maps= -o relay_recipient_maps= -o mynetworks=127.0.0.0/8 -o smtpd_restriction_classes= -o smtpd_delay_reject=no -o smtpd_client_restrictions=permit_mynetworks,reject -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o smtpd_data_restrictions=reject_unauth_pipelining -o smtpd_end_of_data_restrictions= -o smtpd_error_sleep_time=0 -o smtpd_soft_error_limit=1001 -o smtpd_hard_error_limit=1000 -o smtpd_client_connection_count_limit=0 -o smtpd_client_connection_rate_limit=0 -o smtpd_authorized_xforward_hosts=127.0.0.0/8 -o receive_override_options =no_address_mappings,no_unknown_recipient_checks,no _header_body_checks === The local destination domain is included in mydestination. My transport map has only one entry for an external domain. I tried removing the '-o receive_override_options=no_address_mappings' and '-o local_recipient_maps=', but nothing changed. I'm out of ideas. I really appreciate your help. Thanks, Tobi
Re: Mail not delivered to local users: status=deferred (mail transport unavailable)
Tobi: Hi All, I set up an after-queue content filter following the instructions on http://www.postfix.org/FILTER_README.html . Everything works fine except that mail directed to local users is deferred when it is re-injected to postfix after the content filter. However, virtual and remote addresses work. I have the trivial-rewrite, qmgr, local, and error daemons running with the -v switch. Here is a `grep id mail.log` for a re-injected mail: Don't turn on verbose logging. You're overwhelming the log with useless information. Instead look at all the screams for help that Postfix already logs. http://www.postfix.org/DEBUG_README.html#logging Wietse
Re: Mail not delivered to local users: status=deferred (mail transport unavailable)
On Mar 29, 2009, at 5:10 PM, Wietse Venema wrote: Tobi: Hi All, I set up an after-queue content filter following the instructions on http://www.postfix.org/FILTER_README.html . Everything works fine except that mail directed to local users is deferred when it is re-injected to postfix after the content filter. However, virtual and remote addresses work. I have the trivial-rewrite, qmgr, local, and error daemons running with the -v switch. Here is a `grep id mail.log` for a re-injected mail: Don't turn on verbose logging. You're overwhelming the log with useless information. Instead look at all the screams for help that Postfix already logs. http://www.postfix.org/DEBUG_README.html#logging Wietse Wietse, Thanks much for pointing this out. It turned out that the problem was caused by: postfix/local[29798]: fatal: main.cf configuration error: mailbox_size_limit is smaller than message_size_limit My bad. Many thanks for your support and the great work on postfix! Tobi
can the deferred mail delivery attempts settings be different for a postqueue filter?
I use an after queue filter to filter incoming email. When the filter queue grows because email comes in faster than it can handle the filter returns a 450 until the filter queue is empty again. Now when email is received in a big burst it can happen that the filter queue temporarily grows and then temporarily blocks. The default settings for redelivery (queue_run_delay, minimal_backoff_time etc.) are suitable for delivery of external email but I would like these settings to be different for email sent to the filter. With the default settings it takes a 'long' time before Postfix detects that the filter again accepts email. Is it possible to have different queue_run_delay, minimal_backoff_time etc. settings for the filter transport? Thanks, Martijn Brinkers
Re: can the deferred mail delivery attempts settings be different for a postqueue filter?
Martijn Brinkers: I use an after queue filter to filter incoming email. When the filter queue grows because email comes in faster than it can handle the filter returns a 450 until the filter queue is empty again. Now when email is received in a big burst it can happen that the filter queue temporarily grows and then temporarily blocks. The default settings for redelivery (queue_run_delay, minimal_backoff_time etc.) are suitable for delivery of external email but I would like these settings to be different for email sent to the filter. With the default settings it takes a 'long' time before Postfix detects that the filter again accepts email. Is it possible to have different queue_run_delay, minimal_backoff_time etc. settings for the filter transport? Yes. Use another Postfix setup (with its own main.cf, master.cf, queue directory and data directory). You can do this with every Postfix release, but Postfix 2.6 makes it easier with one command to start and stop. All Postfix versions: http://www.postfix.org/postconf.5.html#alternate_config_directories Postfix 2.6: http://www.postfix.org/postfix-wrapper.5.html Wietse
Re: can the deferred mail delivery attempts settings be different for a postqueue filter?
Wietse Venema wrote: Martijn Brinkers: I use an after queue filter to filter incoming email. When the filter queue grows because email comes in faster than it can handle the filter returns a 450 until the filter queue is empty again. Now when email is received in a big burst it can happen that the filter queue temporarily grows and then temporarily blocks. The default settings for redelivery (queue_run_delay, minimal_backoff_time etc.) are suitable for delivery of external email but I would like these settings to be different for email sent to the filter. With the default settings it takes a 'long' time before Postfix detects that the filter again accepts email. Is it possible to have different queue_run_delay, minimal_backoff_time etc. settings for the filter transport? Yes. Use another Postfix setup (with its own main.cf, master.cf, queue directory and data directory). You can do this with every Postfix release, but Postfix 2.6 makes it easier with one command to start and stop. All Postfix versions: http://www.postfix.org/postconf.5.html#alternate_config_directories Postfix 2.6: http://www.postfix.org/postfix-wrapper.5.html Wietse Seems to me the first action should be to reduce the number of smtp connections to the content_filter to a number it's able to consistently handle. If that's ineffective for some reason, then implement the suggestions outlined in http://www.postfix.org/QSHAPE_README.html#backlog -- Noel Jones
Re: can the deferred mail delivery attempts settings be different for a postqueue filter?
On Fri, Jan 30, 2009 at 11:43:07AM -0600, Noel Jones wrote: If that's ineffective for some reason, then implement the suggestions outlined in http://www.postfix.org/QSHAPE_README.html#backlog Note, for Postfix 2.5.x with x=6, there is an error in the parameter names actually used by qmgr(8), and: http://www.postfix.org/QSHAPE_README.html#backlog fragile_destination_concurrency_failed_cohort_limit = 100 needs to be augmented by an alias: fragile_concurrency_failed_cohort_limit = $fragile_destination_concurrency_failed_cohort_limit so that the queue manager's incorrect lookup returns the desired result. This will be corrected in 2.6 and I expect at some point also 2.5.7. -- Viktor. Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. To unsubscribe from the postfix-users list, visit http://www.postfix.org/lists.html or click the link below: mailto:majord...@postfix.org?body=unsubscribe%20postfix-users If my response solves your problem, the best way to thank me is to not send an it worked, thanks follow-up. If you must respond, please put It worked, thanks in the Subject so I can delete these quickly.
Re: can the deferred mail delivery attempts settings be different for a postqueue filter?
On Fri, 2009-01-30 at 11:43 -0600, Noel Jones wrote: Seems to me the first action should be to reduce the number of smtp connections to the content_filter to a number it's able to consistently handle. There is a big difference in filtering speed between messages. The filter is an encryption filter and encryption speed depends largely on the message size. The connection between Postfix and filter need to be fast enough to handle small messages. If that's ineffective for some reason, then implement the suggestions outlined in http://www.postfix.org/QSHAPE_README.html#backlog If I'm not mistaken the described approach (with fragile_destination_concurrency*) works when you have small bursts of errors. In my case it can take some time before connections are allowed (email is again allowed when the filter queue size drops below a level). Currently my filter return 450 when the queue is below a certain level. Would it be better if I add connection 'throttling' instead of immediately returning 450? So: If the filter queue size is larger than 500 messages (lower level) wait some time X in the RCPT handler of the filter and then continue normally. If size is larger than 1000 (upper level) return 450. This would slow down the message rate between Postfix and filter without immediate blocking. Thanks, Martijn
Re: can the deferred mail delivery attempts settings be different for a postqueue filter?
Martijn Brinkers wrote: On Fri, 2009-01-30 at 11:43 -0600, Noel Jones wrote: Seems to me the first action should be to reduce the number of smtp connections to the content_filter to a number it's able to consistently handle. There is a big difference in filtering speed between messages. The filter is an encryption filter and encryption speed depends largely on the message size. The connection between Postfix and filter need to be fast enough to handle small messages. But there probably isn't a big difference in the number of simultaneous messages the filter can handle, independent of message size/content. I still think this should be the first action. If that's ineffective for some reason, then implement the suggestions outlined in http://www.postfix.org/QSHAPE_README.html#backlog If I'm not mistaken the described approach (with fragile_destination_concurrency*) works when you have small bursts of errors. In my case it can take some time before connections are allowed (email is again allowed when the filter queue size drops below a level). The example tolerates up to 2000 consecutive errors. Remember it's an example and can be seasoned to taste. Currently my filter return 450 when the queue is below a certain level. Would it be better if I add connection 'throttling' instead of immediately returning 450? So: If the filter queue size is larger than 500 messages (lower level) wait some time X in the RCPT handler of the filter and then continue normally. If size is larger than 1000 (upper level) return 450. Seems to me something is broken if the filter processing speed is affected by the size if the postfix queue. -- Noel Jones
Re: can the deferred mail delivery attempts settings be different for a postqueue filter?
Victor Duchovni wrote: On Fri, Jan 30, 2009 at 08:14:22PM +0100, Martijn Brinkers wrote: If I'm not mistaken the described approach (with fragile_destination_concurrency*) works when you have small bursts of errors. In my case it can take some time before connections are allowed (email is again allowed when the filter queue size drops below a level). Currently my filter return 450 when the queue is below a certain level. Would it be better if I add connection 'throttling' instead of immediately returning 450? So: Eliminate all queues from the filter, it should be a proxy. Let Postfix do all the queueing, it is much better at this than the filter. I didn't consider that the filter might not be a proxy. If that's the case, the design of the filter is broken and it will be difficult to fix in postfix. -- Noel Jones
Re: can the deferred mail delivery attempts settings be different for a postqueue filter?
On Fri, Jan 30, 2009 at 01:45:29PM -0600, Noel Jones wrote: Victor Duchovni wrote: On Fri, Jan 30, 2009 at 08:14:22PM +0100, Martijn Brinkers wrote: If I'm not mistaken the described approach (with fragile_destination_concurrency*) works when you have small bursts of errors. In my case it can take some time before connections are allowed (email is again allowed when the filter queue size drops below a level). Currently my filter return 450 when the queue is below a certain level. Would it be better if I add connection 'throttling' instead of immediately returning 450? So: Eliminate all queues from the filter, it should be a proxy. Let Postfix do all the queueing, it is much better at this than the filter. I didn't consider that the filter might not be a proxy. If that's the case, the design of the filter is broken and it will be difficult to fix in postfix. If the filter wants to queue, it should accept mail essentially regardless of its queue size. If latency is too high, add more filter boxes. In practice the filter's queue should be always empty, with occasional small spikes for bursts of large messages that gobble-up CPU. The spikes should die down quickly. If this is not the case, add more horse-power. -- Viktor. Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. To unsubscribe from the postfix-users list, visit http://www.postfix.org/lists.html or click the link below: mailto:majord...@postfix.org?body=unsubscribe%20postfix-users If my response solves your problem, the best way to thank me is to not send an it worked, thanks follow-up. If you must respond, please put It worked, thanks in the Subject so I can delete these quickly.
Re: can the deferred mail delivery attempts settings be different for a postqueue filter?
iminate all queues from the filter, it should be a proxy. Let Postfix do all the queueing, it is much better at this than the filter. The filter is based on James which is a Java based email server and cannot be used as a proxy, at least not without a major overhaul. The biggest reason I added the max queue size check to the filter is that Postfix is much better in queuing than James. Are there any drawbacks, Postfix wise, when using connection throttling for the filter?
Re: can the deferred mail delivery attempts settings be different for a postqueue filter?
On Fri, Jan 30, 2009 at 09:00:26PM +0100, Martijn Brinkers wrote: iminate all queues from the filter, it should be a proxy. Let Postfix do all the queueing, it is much better at this than the filter. The filter is based on James which is a Java based email server and cannot be used as a proxy, at least not without a major overhaul. The biggest reason I added the max queue size check to the filter is that Postfix is much better in queuing than James. Are there any drawbacks, Postfix wise, when using connection throttling for the filter? You are solving the wrong problem. Your filter absorbs mail too fast, queues it and then pushes back. It is far better for the filter to take its time before responding to . and thus to tie up Postfix connections while the filter is catching up. Also sounds like your filter is not able to process mail as fast as it is coming in. If that is the case you can never win. The peak output rate has to be above the average input rate. -- Viktor. Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. To unsubscribe from the postfix-users list, visit http://www.postfix.org/lists.html or click the link below: mailto:majord...@postfix.org?body=unsubscribe%20postfix-users If my response solves your problem, the best way to thank me is to not send an it worked, thanks follow-up. If you must respond, please put It worked, thanks in the Subject so I can delete these quickly.
