On Mar 17, 2008, at 12:31 PM, Hector Santos wrote:
You need to throw way the whole idea of mandating an MX. MX is for
OUTGOING mail. DKIM is for INCOMING mail.
While MX and A records are used to discover inbound SMTP servers, they
can also play a role in determining whether the domain might also be
publishing DKIM related policy.
A default behaviour used by some MTAs is to log PTR records found
within the in-addr.arpa reverse zone for those SMTP clients attempting
to connect. In many cases, DNS for this zone is not configured
properly, either though the lack of delegation or authoritative
responses. Errors within the reverse zone are common, where resulting
processing delays often represent a significant portion the MTA's
overhead. Despite its high burden, acceptance often does not demand
the reverse zones be properly configured, since forward and reverse
zone are often managed by separate entities.
However, acceptance of a message may demand an MX or A record be
published within the forward zone. While there are excuses for poorly
configured reverse zones, fewer exist for the forward zone. MX or A
records published in the forward zone are necessary to discover
receiving MTAs. As a result, some MTAs qualify acceptance by testing
whether originating domains publish a requisite A or MX discovery
record. While these records are not essential for receiving a
message, these records are essential for any subsequent reply. An
inability to reply may disqualify the domain as being considered
valid. In addition, checks within the forward domain often involve
less process time overhead.
By mandating MX records in conjunction with DKIM policy records,
simpler tests can be applied when receiving a message lacking a DKIM
signature that is within the From header domain. This category will
represent the majority of messages received. To cope with wildcard,
such as use of a xptr scheme or A record substitution, an empty policy
record in conjunction with the absence of an MX record can define a
policy state disavowing DKIM/SMTP. This state avoids reliance upon
detecting the non-existence of the domain.
In addition, assessing DKIM policy and MX record presence eliminates a
need for any domain tree walking.
The following tests can be made when a message is not signed by the
From domain which starts with a transaction requesting the MX record.
1) When no MX record:
A) Query for policy record.
i) When policy record (even empty), reject message.
ii) When no policy record, query for A record.
a) When no A record, reject message.
b) When A record, assume no policy.
2) When MX record:
A) Query for policy record.
i) When no policy record, assume no policy.
This Policy/MX record approach allows dealing with wildcards by
publishing *.@ TXT "", or by requiring existing nodes contain an empty
policy record such as _adsp.example.com TXT "". This combined record
approach requires a few domains seeking DKIM policy protection to
ensure a minimum number of DNS transactions are required by
recipients. The goal is not to make publishing easier, but to ensure
determination of the presence of policy requires the fewest number of
transactions possible without affecting a parent domain or requiring
the use of wildcards.
NOTE WELL: This list operates according to