ietf-dkim
[Top] [All Lists]

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