Forum Discussion
NimbostratusMultiple remote connections, return first responder?
I'm trying to send SMTP mail to a remote provider (unrelated to my company, just trying to send mail). We send this provider a lot of mail, and their servers are frequently broken. They have two IP addresses to connect to, and often, one of them will not respond at all. This means I have to wait for a TCP timeout before I can retry, significantly delaying delivery and tying up threads on my end.
Unfortunately, the remote provider has no desire to rectify this issue. So I'm trying to figure out if I can have some sort of internal role IP which my clients connect to on the F5. The F5 then attempts connections to both IP's simultaneously, and whichever responds first, is handed back to the local client. The other session is dropped.
I'm just not really sure where to start with this. Any suggestions?
Cheers,
Chris
6 Replies
HamishCirrocumulus
Hmmm...
While you could do something with a local VS and over0riding their MX record at your own DNS servers, in that path lies madness... Especially when they move their servers...
Do you not run a local SMTP relay internally? Remember SMTP isn't a real-time protocol...
H- Chris_Miller
Altostratus
Could probably make a pool containing the two IPs and some sort of health check? 
cmoatesI can't make a VS with remote IP's though, can I?And yes, SMTP isn't a real time protocol, and I'm reducing the time I'll wait for a TCP connection to help mitigate the issue, but what happens is that I'll end up with so many of these in my outbound queue that no mail is delivered to anyone, while the threads all spin on a TCP timeout.
- HamishYeah, remote poolmembers are fine. As long as you use SNAT (Or as long as the route back to the client is returned via the f5).
H - HamishPosted By cmoates on 12/15/2010 08:41 AM
And yes, SMTP isn't a real time protocol, and I'm reducing the time I'll wait for a TCP connection to help mitigate the issue, but what happens is that I'll end up with so many of these in my outbound queue that no mail is delivered to anyone, while the threads all spin on a TCP timeout.
Mmm... What sort of software are you using for your MTA? FWIW I used to run postfix with hundreds of thousands of emails per day... For slow sites, you can usually set a maximum number of connections to use.. e.g. 1... (AOL was usually pretty bad sometimes for this).postfix will also remember about bad relays... And will extend the time between attempts for ones that are continually bad.
H
- cmoatesWe make one initial attempt to deliver mail internally in our application before tossing it off to an MTA to sit in retry-land. While you and I may both know that SMTP isn't real time, the vast majority of the unwashed masses have gotten used to the fact that it operates like a real-time service most of the time, and so we're trying our best to accommodate them, while still maintaining our sanity. Since it's very rare that this provider's primary and secondary MX's are unavailable at the same time, I thought the F5 might provide a nice solution whereby minimal app changes are required.
