On 02/11/2011 06:22 PM, Zach Wily wrote:
On Friday, February 11, 2011 at 10:03 AM, Jeroen Geilman wrote:
On 02/11/2011 05:50 PM, Zach Wily wrote:
This was designed to implement a graveyard service for mail
that can't be delivered via the preferred service.
http://www.postfix.org/postconf.5.html#smtp_fallback_relay
I tried this, but when a message to aws-email fails, it enters SOFTBOUNCE state
and sits in the queue.
You have soft_bounce = yes enabled.
This is a bad idea for production systems.
http://www.postfix.org/postconf.5.html#soft_bounce
I'm not sure it's a bad idea on this system. The only email it is sending is
from a local application. In the event that delivery fails, I'd like the
messages to stay queued and retried later. This has been helpful before, like
when we hit our AuthSMTP quota without knowing it. Once we fixed the situation,
the queue would empty and all the message go out.
Is there something bad about soft_bounce that I'm missing?
Either way, I tried turning it off, and I still didn't get the behavior I want. When I hit Amazon's limit, emails started failing and were not delivered via AuthSMTP. The relevant config looked like this:
soft_bounce = yes
default_transport = aws-email
This is a transport.
smtp_fallback_relay = [mail.authsmtp.com]:2525
This is a mail host.
In the normal case, your mail would be queued for
aws-email:destination.domain
In case this causes errors, it would re-queue to
aws-email:[mail.authsmtp.com]:2525
I would suggest you use relay_host = [amazon.ses.server] instead.
--
J.
