David Gomillion wrote:
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.
I don't think smtp is supposed to be such a stateless protocol as you
imply. And it is not a new suggestion created by me. In RFC 2821 we can
read:
"When the lookup succeeds (the MX lookup), the mapping can result in a
list of alternative delivery addresses rather than a single address,
because of multiple MX records, multihoming, or both. To provide
reliable mail transmission, *the SMTP client MUST be able to try (and
retry) each of the relevant addresses in this list in order, until a
delivery attempt succeeds*."
Pretty clear isn't it? Sadly RFC 2821 isn't as clear as some might wish.
There are a few considerations on this matter latter on RFC 2821 that
state otherwise. The main reason presented there for not trying "each of
the relevant addresses in this list in order, until a delivery attempt
succeeds" would be "unnecessary resource use".
I bet present Courier implementation is based on optimized resource use
considerations. As I mentioned in my first messages, the alternative
behaviour I'm suggestion could be an option. I believe this alternative
delivery method would be more reliable than the present one. People
could choose the one they prefer.
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.
Man, I can only say you proposed a rather convoluted idea. It might be a
good idea, but I'm not sure.
I'm talking about something really simplier.
Thanks for your consideration,
Rodrigo
-------------------------------------------------------
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
