On Jun 13, 2007, at 3:47 AM, Charles Lindsey wrote:
On Tue, 12 Jun 2007 01:28:05 +0100, Douglas Otis <[EMAIL PROTECTED]
abuse.org>
wrote:
So when wildcard records are not used,
after receiving a message considered not signed:
- When neither an MX (or A) record are found, refuse the message.
- When an MX (or A) record are found, query for a policy record.
- When no policy is found, there is no policy. (Searching not
required.)
- When policy requires DKIM signatures, refuse the message.
That works for the domain that "never sends mail" "never receives
mail"
But what about the domain that receives, but never sends?
In that case you will publish several MX records (with assorted
preferences) as usual. But then you also publish an extra MX record
with a ridiculously low preference (99 say) which points to
something unresolvable (e.g. nomail,invalid).
Had DKIM policy permitted such a statement, it could be handled via
policy. However, this is a rather odd case for anti-spoofing. Any
DKIM policy related protection will require such a "never sending"
domain to lie. In this case, the "never sending" domain must
indicate they "always sign" the email they "never send".
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.
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. The impact of this change may eventually mean messages
from a domain might be refused without there being an MX record
within this domain.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
