SMTP Minimum Retry Period - Proposal To Modify Mx

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



-----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-----


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]