2009/9/2 Martin Brown:
> We've hit an issue when sending via Postini from James.
> The destination email system has two servers listed in DNS, one with
> cost 10 and the other with cost 20. The server with cost 10 does not
> accept connections. The other appears ok.
> Postini don't spool email - they operate as a thin proxy. Therefore when
> the connection fails Postini send back a 400 code. The intention is that
> the originating email server retries the send immediately on the same
> connection. Postini will then try to deliver the email to the higher
> cost MX server.
a 400 code can't be used when the "intention is that the originating
email server retries the send IMMEDIATELY", instead a 400 means that
temporarily this cannot be delivered, retry later (I don't know any
MTA that retries immediately after a 400).
> James operates according to the RFCs and queues the message for a later
> delivery attempt. However, since the later delivery is on a new TCP/IP
> connection, Postini has lost the state and retries delivery to the lower
> cost MX server. Thus delivery can never succeed.
AFAIK James, when receiving a 400 from the MX 10 will try to connect
to the MX 20 and only after both fail temporarily it will put the mail
in spool for a later retry. When a retry is needed it will start again
with an attempt to MX 10 followed by an attempt to MX 20. So both
servers should be tried multiple times, until one either send a
permanent failure or enough attempts have been made.
0:00 attempt to MX 10 <-- 400
0:00 attempt to MX 20 <-- 400
0:00 store in spool for a later attempt
0:10 attempt to MX 10 <-- 400
0:10 attempt to MX 20 <-- 200 ok..
> Has anyone found a workaround to this issue? I can't see anything in the
> RFCs that specify the behaviour that Postini rely on, but I can't see
> them changing the way their email system works.
I send to "postini" inboxes all the time and I didn't notice such a
behaviour. (I use my own remote delivery code but mostly similar to
the james one).