> Ben Kennedy wrote: > > >Sam Varshavchik wrote at 9:02 am (-0400) on 21 6 2005: > > > > > > > >>So, until modern technology advances to such a point, the > only logical > >>thing > >>to do is attempt to deliver E-mail repeatedly, and follow > the preferred > >>logic for making each delivery attempt: pick a primary MX > at random, if you > >>can't connect it to it, pick a secondary MX at random, and so on. > >> > >> > > > >I have to admit I am starting to come around to > understanding Rodrigo's > >viewpoint on this, however. What is the *downside* of > having Courier > >retry a different (same-priority if exists, or next lowest, > as usual) > >MX rather than the same *potentially*-broken one, after the usual > >interval? > > > > > Yes, that's precisely my point. > > >It won't be construed as a spam attempt, unless I guess you > are of the > >opinion that my sending two separate messages to you and > happening to > >have them connect to two different MX is also spammy > behaviour (no, it > >would just be coincidence). > > > > > That's my understanding also.
What you're suggesting here makes some sense, but you have to think about it from a bigger-picture perspective. Basically, you're trying to change stateless SMTP handling based upon MX records into a stateful system that remembers broken MXes and acts on that knowledge. This could help some cases, but in most cases, this is simply going to create a new superstructure of information and processing of that information. And keep in mind that for most mail servers, they're only going to send a few mails to each domain, except for a few tight partners with whom they trade lots of mail. If it's a high-volume associate, you could probably lean on them to fix their servers or update the DNS. If it's someone you only send a couple pieces of mail to once in a while, then let the messages go at the best-effort way they do now. The only way this would be viable, in my opinion, is if we created a new project that used DNS to query for the MX records, passed the best one to the mail server, and then received a report from the mail server (pass or fail) for that MX. We would save the information and base our future suggestions of the best MX on this information. Thus, servers that never allow mail through will not be recommended as the best choice, while those that operate correctly will. Doing something like this, however, would completely undermine the MX system in place, and take control out of the hands of the local administrator, who are supposedly the best-informed of what's actually going on. Suppose for a moment that you have the following scenario: Primarymail.nowhere.com 10 Othermail1.nowhere.com 20 Othermail2.nowhere.com 20 Othermail3.nowhere.com 20 Now suppose Primarymail has a memory problem and just stops responding after receiving a small portion of the body of the email. So, the connections keep timing out. Under the above proposal, it would be marked as BAD. You try Othermail2.nowhere.com as your random choice. It has the same problem. It is marked as BAD. You try Othermail3.nowhere.com as your second choice. Again, same problem. It too is marked as BAD. Finally, you try Othermail1.nowhere.com. It works. Hooray! Ok, now 30 seconds later, you have another email to send. Do you try Primarymail.nowhere.com first? It's been marked as bad, right? Well, it's weight is 10, so you really ought to try it first. On the second round, the only mail server not marked as BAD is Othermail1.nowhere.com. So you try it. But it fails. The key is, the clueful administrator of nowhere.com is in the process of switching the host records to point to the email servers in such a way that the working email server will become Primarymail.nowhere.com. But you hit it at a bad time. Maybe DNS caching with your provider screwed everything up. Maybe he was changing the IP addresses on the servers. Maybe Godzilla decided to chew on the Cat5 cable at just the wrong time. The point is, you have no knowledge of what is going on there. And you shouldn't have to. So, what do you do? Do you unmark all of the failed MX records? Do you have a score that keeps accruing based on how many bad responses are received? What is bad, anyway? 4xx? 5xx? Connection refused? And how much more complexity did we add, and for what gain? I think such a system could work. It would take a lot of work on a powerful back-end, and it would take a lot of work with all the different email servers, as each would have to query our DNS and send us a response. But in the end, it could work, much like the DNS blacklists. But the real solution is to let the administrators fix their email servers, and let the DNS fixes propagate out. If the administrator can't do this, then they don't deserve to get email anyway! I know we've had problems in the past, and I'm glad that most mail servers will queue up emails for a while and keep trying until we're back up. And even with a T1, we have experienced downtime, so don't tell me it's only with dial-up! Part of the beauty of SMTP is it's simplicity. Servers do not have to know anything about where they are sending the message. They don't have to remember any information between connection attempts. They simply do what they're supposed to in the same way every time. Anything we did to mess with that would have to have serious advantages that couldn't be accomplished any other way! SMTP may be broken, but it's ubiquitous. If we're going to go to such lengths to try to fix something that works OK when properly configured, we might as well go and invent a new protocol that fixes other limitations. But that sounds like a Redmond solution, after all. Just some thoughts, David Gomillion ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
