Subject: SMTP Minimum Retry Period - Proposal To Modify Mx

From: "Sabahattin Gucukoglu" <[email-masked]>
Date: Fri, 09 Jan 2004 16:48:28 -0000

Hi people,

I have a friend whose on ADSL and who wants to run his own email service, 
but is periodically disconnected.  He likes his mail delivered straight to 
his primary host, but his mate is there across the other side of the 
country if ever he's out as a backup MX.  Now, every time he uses the 
connection, which is at least once every few hours and at most once a day, 
his connection automagically reestablishes itself.  While he's been down, 
though, any mail destined for him has gone to his mate, who only delivers 
mail once every four hours or so.  By misfortune, my friend has gone down 
just as a mail was being queued for sending, in a place far away.  Being 
down, he can't take the mail, so his mate takes it for him.  He must wait 
four whole hours, assuming he has come up after the delivery of that 
message to his mate, even if the originating client was willing to deliver 
it sooner - say, thirty minutes, if his mate hadn't been around.  There's 
just one more condition - his mate, though great as mates go, is an anti-
RBL purist.  He refuses to use RBLs.  His mate is picking up spam which he 
would have rejected, had he been responsible, and it isn't reasonable to 
parse the mail after the mail is accepted, in particular because he's 
serving other people and doesn't justify this kind of intrusive filtering.

Now, all that was mostly hypothetical - based on a true story.  If my 
friend is some poor soul on ADSL, and his mate (that is, friend, just in 
case - buddy for the Americans) is a dynamic service provider with backup 
MX facilities or some organisation who can't reasonably be expected to 
alter their mail service policies to be in line with that of my friends 
who are of my anti-spam, direct-to-destination kind with no wish to be at 
the mercy of our ISPs, we need some mechanism to tell the SMTP client to 
keep trying to deliver to a particular MX(es), for a particular time(s).

My proposal: an extension to the MX record in the DNS, which must be 
backward compatible with existing MX records - that is, non-conformant 
mailers must not be confused by the new form of the record.  The creation 
of a new record type must only be necessary if that record type may 
facilitate many such extensions, not just this one.  This use of the MX 
might look like:
example.org: mx 10 example.org 86400
(Or, if the record - new or existing - is used extensibly, something like 
"mx 10 example.org MRP86400")
Where 86400 is the minimum number of seconds (1 day) for which the MX must 
be tried before those of lower priority must be tried.  If other MX 
records exist with same preference, then the same rule applies to those 
hosts, except that the delivery timeouts occur in parallel, and no MXs of 
lower preferences are to be tried until all MXs at this preference have 
been tried - that is, if:
mx 10 mx1.example.org 60
mx 10 mx2.example.org 30
mx 20 mx3.example.org
Then mx1.example.org and mx2.example.org will be tried simultaneously 
(that is, one after another but immediately following as in normal MX 
selection and delivery attempt behaviour), with the client giving delivery 
attempts whenever it usually does at whatever intervals it normally uses 
until the timeout occurs on mx2, at which point only mx1 is continually 
assaulted with the same algorithms as before, until it to is deemed 
unusable - 30 seconds later (hypothetical numbers, we'd normally be 
talking many hours!).  Only at this point is mx3 tried, which may or may 
not have such a minimum time given, and the same algorithm procedure is 
used at this preference.  As you see here the mx3 is listed without the 
MRP, which may be away of avoiding compatibility issues.

Where local policy dictates differing delivery times and intervals, the 
time given in the DNS must always be respected - so, if you deliver first 
at 30 minutes, then at 60 following, then 2 hours, then 4 etc. in a 
typical backoff style, then the sum of these times preceding must be 
waited against the value in DNS (in seconds).  If the total time spent 
attempting delivery to this host is now exceeded, then - at discretion of 
administrator - the unreachable host may be tried once more.  In any 
event, it is now permissible to proceed to lower-priority MXs.

Since this is meant to be backwards-compatible, there's a possible 
argument that mandating the attempts for the MRP for compliant systems is 
a bit counter-intuitive; I'm hoping that enough systems could do this to 
make it worthwhile, and there's no other way of achieving the same thing 
without an MX knowing when another MX of higher preference was both 
available and not available (the latter obviously being very hard to 
advertise, because it aint available!) with which knowledge the MX could 
either accept the mail or refuse to accept mail on the grounds that the 
higher MX was already available.

Of course, this little flash of brilliance ( :-P ) is only going to work 
if we can bend the DNS without anyone noticing.  Which, chances are, they 
will.  RFC 2821 which replaced RFC 974 before it on this matter makes no 
reference to the exact way in which MX records should be parsed, so that 
it could be chancy.

Still, what do you all think?

Cheers,
Sabahattin
- -- 
Thought for the day:
    Book (n): a utensil used to pass time while waiting
    for the TV repairman.

Latest PGP Public key blocks?  Send any mail to:
<[email-masked]>

Sabahattin Gucukoglu
Phone: +44 (0)20 7,502-1615
Mobile: +44 (0)7986 053399
http://www.sabahattin-gucukoglu.com/
Email/MSN: <[email-masked]>

-----END PGP SIGNATURE-----

---

From: Bill Sommerfeld <[email-masked]>
Date: Sat, 10 Jan 2004 09:20:56 -0500

> The RBL, and particularly the DUL, are not "good faith," as it is
> well known that both block significant amounts of legitimate,
> non-spam, non-uce, recipient-desired email.

I guess it depends on your definition of "significant".  I haven't
noticed a problem, but the amount of spam I get is large enough that,
in good faith, I'm willing to tolerate a modest number of false
positives.

					- Bill

---

From: [email-masked] (Mike S)
Date: Sat, 10 Jan 2004 11:28:52 -0500

At 06:41 PM 1/9/2004, Vernon Schryver wrote...

>Could you point to significant amounts of real mail, as opposed to
>theoretical examples, that might reasonably have consider legitimate
>by its targets but that was rejected as the result of a MAPS RBL
>listing?  Note that the validity of mail is determined not its senders
>but by its targets.

Yes. For a lengthy period, all mail.com SMTP servers were included in the RBL, blocking significant numbers of legitimate, private, non-spam emails from reaching willing recipients.

---

From: [email-masked] (Mike S)
Date: Tue, 13 Jan 2004 07:56:12 -0500

At 10:45 PM 1/12/2004, Vernon Schryver wrote...
>Mr. Sauve could rent an IP address that is not on dial-up or dynamic
>blacklists and run his systems there.

Proven wrong, Vernon now changes his tack to one of trying to rationalize interference with legitimate email and attempting to place the burden on those who wish to use the Internet as designed, not as damaged by his beloved blacklists.

As I said, fascist. He has learned to use whois and Google, though, and seems very self-impressed at his ability to learn such simple things. He has apparently not, however, discovered dictionary.com. "In the design of ... software tools, 'the fascist alternative' is the most restrictive and structured way of capturing a particular function;"