-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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:
<PGPPublicKey@xxxxxxxxxxxxxxxxxxxxxxxx>
Sabahattin Gucukoglu
Phone: +44 (0)20 7,502-1615
Mobile: +44 (0)7986 053399
http://www.sabahattin-gucukoglu.com/
Email/MSN: <mail@xxxxxxxxxxxxxxxxxxxxxxxx>
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0 -- QDPGP 2.70
Comment: Previous key for <Sabahattin_Gucukoglu@xxxxxxxxxxxxxxxxx> revoked due to invalidated primary address.
iQA/AwUBP/7bXCNEOmEWtR2TEQJyuwCeIbafW2tUrQFEXF9UfJcU2yXmo8YAnj1G
Ym/1XpLknxQbZeEclG8gzoiR
=VDSt
-----END PGP SIGNATURE-----
-----END PGP SIGNATURE-----