[Top] [All Lists]

Re: How to mark domains that do / do not wish to receive email

2008-03-27 00:51:18

Hi all,

My very strong opinion is that the zero-preference-MX rule must still 
stand, regardless of how to tackle the domain-owners' problem.  It's law.  
It's also often useful, especially when the DNS administrator isn't handy 
and you want mail service on a single public host, especially on a 
temporary basis.  (It's amusing to think that, now that MX records are the 
commonality for which a transition plan was provided for non-users when 
first introduced, spammers often don't spam hosts without them because of 
their near-universal ubiquity.)

It doesn't matter what itch needs to be scratched to make MX or DNS usage 
perfect; taking the rule away is _going to break compatibility with old 
clients_.  And that's all.  When MX records were introduced, we would 
never have dreamed of doing a thing like that.  So why are we even 
contemplating it now?  (I think I've caught up with all of the discussion 
so far, but please point me to anything if it's already been answered.)

To address the problem that begs for the rule's removal, however: how 
about a fake MX that rejects everything as the draft-rfc2821-bis allows 
with the 554 code on connection opening?  How about not minding that the 
sending host is the one with the problem, and not you (not nice, so it'd 
be good to sort it out)?  How about using a known-nonexistent (EG: 
definitely.invalid) host as your MX target (has more bad effects than 
known behaviour but at least it works - and when the rules don't allow us 
to do better than that for now, that's all we can hope for)?  This "MX 0 
." sounds good as well, because it only requires time for implementers to 
get the idea and implement it while it's a bit of bother in the meantime.

So no, please don't drop that rule.  It's very handy, anyway, even if it 
is an irritating little blister just yearning to be popped, both to make 
semantics and practice clean and current for DNS and SMTP.  But we spent 
ages making the MX record what it is - a record for indicating the names 
and preferences of mail exchangers, with a known behaviour for absent MX 
records.  Changing the meaning of MX from being just a preference list to 
an actual indicator of whether mail is wanted or not would not have made 
sense at the time, and I feel strongly that it still hasn't got even the 
slightest motive for doing so today when practical and long-term solutions 
that can work without breaking compatibility seem possible with the 
minimum of badness.


Sabahattin Gucukoglu <mail<at>sabahattin<dash>gucukoglu<dot>com>
Address harvesters, snag this: feedme(_at_)yamta(_dot_)org
Phone: +44 20 88008915
Mobile: +44 7986 053399