On May 12, 2008, at 3:20 AM, Eliot Lear wrote:
Charles Lindsey wrote:
On Fri, 02 May 2008 13:02:10 +0100, Eliot Lear <lear(_at_)cisco(_dot_)com>
wrote:
Charles Lindsey wrote:
Fine! Then let us write a BCP.
No. The more documents people need to read to understand the mail
system, the more difficult it is to implement and deploy.
Fine! Then adopt my second suggestion, which was to make the BCP a
clearly designated section within the ADSP document.
That would second best, but these are games. Put the information
where it logically belongs, AS VIEWED FROM THE READER'S
PERSPECTIVE. Right now this group is playing bureaucratic games
while we all know the right answer. It's just astonishing.
Eliot,
Are you suggesting games prevent adoption of a process expecting MTAs
to query parent domains for ADSP records whenever these records are
not found within the From email-address domain?
In general, the ADSP draft should describe specifically the public
protocol protected by its policy assertions, and how policy should be
discovered and applied.
Even in a minority of cases where an email-address is not spoofed,
parent ADSP checks will cause transactions to be generated against
domains _not_ involved with SMTP for _each_ incoming email. Also,
these transactions will typically offer little benefit due to ADSP
scarcity making these empty transactions nearly worthless.
However, a BCP may be needed to aid domains not implementing SMTP,
DKIM and ADSP in how to protect themselves from transactions caused by
an egregious level of transactions associated with SMTP, such as ADSP
policy discovery processes. : (
How can uninvolved domains seek protection? Domains may exist without
containing resource records. Must all domains publish ADSP records to
terminate what might become a torrent of transactions? A high
percentage of SMTP messages are sent by opportunistic bad-actors that
might also have a malevolent intent.
Don't expect the world will publish ADSP records at every domain any
time soon. A more reasonable, immediate, and obtainable goal would be
to insist the few domains supporting SMTP that have yet to publish MX,
to publish or their public messages might not be accepted. This type
of mandate impacts only a small number of domains. These domains
could be white-listed to assist with an interim MX mandate
transition. ADSP should support the MX record first philosophy by
specifying a discovery process that first checks for MX records in the
email-address domain before proceeding with other related transactions.
With such an MX mandate, domains not publishing MX records are
protected from additional transactions and connections caused by
spoofed email-addresses. This mandate does not alter the SMTP
discovery process. It only establishes an expectation that any public
email-address exchanged by SMTP be confirmable by the existence of an
MX record. This avoids the myriad of SMTP opt-out strategies such as
"MX .", "TXT v=spf1 -all", or "TXT DKIM=DISCARDABLE".
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html