On Feb 12, 2008, at 7:53 AM, Frank Ellermann wrote:
Douglas Otis wrote:
the SSP draft should mandate publishing MX records whenever an SSP
record is also published.
SSP (or ASP) have no business to "mandate" MX records, that's not
their job. MX records are not required for (2)821(bis)
interoperability, and RFC 2119 has a very clear policy about
The MUST only occurs in conjunction with publishing SSP records. This
does not mandate publishing of MX records when SSP is not used.
Since the SSP discovery process makes use of MX record queries to
determine whether the domain exists
It could as well use A, AAAA, NS, TXR, RP (FWIW), etc. AFAIK it
uses MX because that might be also used (i.e. cached) for other
tasks of the MTA.
Agreed, however by querying for the MX record, there are no wasted
transactions to find an SSP record without an MX record. Importantly,
this result can also truncate policy discovery processes to improve
protections of the parent domains as well as disavowing these messages
to truncate any number of possible signature validation attempts as
then when an SSP record is returned for a domain that has not
published an MX record, this thereby signals that both email and
DKIM are NOT used for email addresses
If there are no mail authors in this domain a statement that these
mails from the "non-existing" authors is always signed suffices to
reject unsigned mails from these "non-existing" authors. For a
domain without users this is a no-brainer, and unrelated to the non-
existence of MX records.
SSP still mandates a query at the parent domain as well as any number
of queries for key records. Once this convention becomes more widely
adopted, it would allow use of A records for purposes other than SMTP
without subsequently causing call back verifications, or policy and
key discoveries. In other words, this lays the foundation to defend
against possible abuse.
For a domain with existing users who are not "permitted" to be mail
authors removing any MX records does not suffice to educate stubborn
Still, this convention offers a level of protection otherwise lost
from the number of transactions added by DKIM and SSP.
DKIM by design does not depend on SMTP. Your proposal mixes
unrelated layers. I like your general MX idea, but is is no SSP
Agreed. There should be a stipulation that only SMTP messages will
have been disavowed.
NOTE WELL: This list operates according to