Re: [ietf-dkim] Jim's issues - one more try
2007-06-14 03:43:14
On Wed, 13 Jun 2007 15:24:59 +0100, Douglas Otis <dotis(_at_)mail-abuse(_dot_)org>
wrote:
On Jun 13, 2007, at 3:47 AM, Charles Lindsey wrote:
By convention, that means "sends no mail". So if you are a receiving
site considering whether some message can be discarded, you just ask to
see the MX records for the domain, and see if they include one pointing
to nomail.invalid.
Of course spammers utilize lower preference MTAs, as might legitimate
senders during network related problems. Low preference
"nomail.invalid" MX records is not a good method to signal that a domain
"only" receives. A "nomail.invalid" will also hammer roots when senders
attempt to resolve the bogus hostname. In the more common case where a
sub-domain does not receive or send, adding an MTA with any preference
and bogus hostname is sure to cause these records to be processed, much
to the detriment of the roots.
Actually, publishing a bogus undeliverable address as your lowest-priority
MX record is one of the standard ways of avoiding spam. Moreover, using an
address ending in ".invalid" in the From: line is the recommended
technique for munging addresses in Usenet articles for those who wish to
avoid their addresses being 'scraped' by spammers (better than to use a
random domain which might turn out to be real, and that would in any case
incur DNS overhead in looking it up). A well organized lookup system
should have '.invalid' hard coded into it as something that never needs to
be queried, but even if this is not done I have been assured that such
bogus addresses will rapidly become cached, and so avoid any undue load on
the root servers. In any case, it will only be spammers who will normally
be attempting to send mail to addresses not capable of receiving it.
And those querying MX records to see if a 'conventional' address such as
'nomail.invalid' is present do not then need to try to retrieve its IP
address.
I reckone there would be no need then to deprecate A records where MX
was absent, or anything like that.
Adding an MX record where an MX record is appropriate, rather than
adding MX records where they don't belong seems a far safer solution.
Deprecation is in respect to utilizing A records for discovery.
But, as has been pointed out to you, that "deprecation of A records" is
just not going to happen. I am just trying to point out an alternative
that might work instead.
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131
Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
|
|