|
Re: [ietf-dkim] Jim's issues - one more try
2007-06-14 19:45:24
On Jun 14, 2007, at 3:33 AM, Charles Lindsey wrote:
On Wed, 13 Jun 2007 15:24:59 +0100, Douglas Otis <dotis(_at_)mail-
abuse.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.
Spam is often highly distributed, perhaps to millions of servers.
When such spam induces DNS resolution of bogus names, negative
responses might be cached for a few minutes, and in some cases not at
all. RFC2308 'suggests' using the SOA minimum field, which is often
1 day at the root. There is _no_ assurance negative caching is
implemented. To safely thwart spammers without hammering roots,
point targets within the MX records to 192.0.2.0/24 address space.
See RFC3330.
In the case of MX records, it is code, not people, that see
"nomail.invalid". A well considered scheme will not induce automated
use of bogus names which might then pound root severs. Perhaps a TLD
of "invalid" could be established. Perhaps IP addresses for
"invalid" names servers could be assigned the address of
"192.0.2.2" After all, who wants to pay for a large amount of bogus
traffic? As it is now, critical roots bear the brunt. Don't assume
publishing bogus names in DNS records is safe, especially with
respect the most abused anonymous push protocols there is, SMTP.
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.
This is _not_ about deprecating A records. It is about deprecating
their use for discovery. More to the point, once a few ISPs refuse
messages from domains lacking MX records, it will not take long
before requisite MX records are published. It can happen faster than
you might imagine. : )
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
|
|