Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Setting up postfix with a fallback transport

856 views
Skip to first unread message

Zach Wily

unread,
Feb 11, 2011, 11:06:30 AM2/11/11
to
Hi everyone.

We've been using postfix + AuthSMTP for quite awhile for our outgoing email notifications. AuthSMTP is getting kind of expensive, so I'm trying to switch to Amazon's Simple Email Service. I've successfully configured postfix to send through SES and it works great, but Amazon throttles you heavily until you've proven yourself as a good email citizen, so we can't just flip the switch to it.

What I'd like to achieve is having amazon-ses as the default transport, and when it starts getting failures, falling back to the authsmtp transport for some time before attempting aws-email again. This would let us send as much as possible through amazon, hopefully getting our quota raised quickly. (We have an aws-email transport set up that sends through a perl script that returns an error on quota overages.)

I've scoured the postfix config docs for a couple hours, but nothing stands out to me as able to do this. The closest thing I can find are the *_destination_concurrency_* options, but those appear to be specific to destinations, not the transports themselves.

Is there some way to accomplish this in postfix?

--
Zach Wily

Wietse Venema

unread,
Feb 11, 2011, 11:11:08 AM2/11/11
to
Zach Wily:
[ Charset UTF-8 unsupported, converting... ]

> Hi everyone.
>
> We've been using postfix + AuthSMTP for quite awhile for our outgoing emai
>-l notifications. AuthSMTP is getting kind of expensive, so I'm trying to swi
>-tch to Amazon's Simple Email Service. I've successfully configured postfix t
>-o send through SES and it works great, but Amazon throttles you heavily unti
>-l you've proven yourself as a good email citizen, so we can't just flip the
>-switch to it.

>
> What I'd like to achieve is having amazon-ses as the default transport, an
>-d when it starts getting failures, falling back to the authsmtp transport fo
>-r some time before attempting aws-email again. This would let us send as muc
>-h as possible through amazon, hopefully getting our quota raised quickly. (W
>-e have an aws-email transport set up that sends through a perl script that r
>-eturns an error on quota overages.)

>
> I've scoured the postfix config docs for a couple hours, but nothing stand
>-s out to me as able to do this. The closest thing I can find are the *_desti
>-nation_concurrency_* options, but those appear to be specific to destination
>-s, not the transports themselves.

>
> Is there some way to accomplish this in postfix?

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

Wietse

Zach Wily

unread,
Feb 11, 2011, 11:50:33 AM2/11/11
to
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. What I'd like is for any failure on the default transport to fall back immediately to AuthSMTP.

zach

Jeroen Geilman

unread,
Feb 11, 2011, 12:03:44 PM2/11/11
to
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

--
J.

Zach Wily

unread,
Feb 11, 2011, 12:22:38 PM2/11/11
to
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
smtp_fallback_relay = [mail.authsmtp.com]:2525


(I have smtl_sasl_password_maps set up which defines the credentials for authsmtp.)

Wietse Venema

unread,
Feb 11, 2011, 1:26:51 PM2/11/11
to
Zach Wily:

> 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. What I'd like is for any failure on the default
>- transport to fall back immediately to AuthSMTP.

Then, you made a mistake. Unfortunately, the crystal ball does not
show what that mistake might be.

Wietse

Jeroen Geilman

unread,
Feb 11, 2011, 2:59:11 PM2/11/11
to
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.

Jeroen Geilman

unread,
Feb 11, 2011, 3:00:54 PM2/11/11
to

Argh. That should be

relayhost = [amazon.ses.server]


--
J.

0 new messages