On Jun 16, 2008, at 2:23 AM, Charles Lindsey wrote:
On Fri, 13 Jun 2008 18:32:07 +0100, Douglas Otis <dotis(_at_)mail-
abuse.org>
wrote:
A Practice should be defined by its specification to cover specific
transport protocols when being asserted by transmitting domains.
It is unreasonable to suggest all transport protocols that might
ever use DKIM must employ DKIM at the same level before an ADSP
assertion can be made. When only SMTP messages uniformly employ
DKIM, then defining ADSP as only covering SMTP permits an assertion
specific to messages introduced by the domain over SMTP. ...
But it also permits every scammer to pretend that his messages were
not really SMTP messages at all, and thus to have them passed
through Verifiers unscathed.
Protection depends upon which ADSP assertion is made. A LOCKED
assertion will cause a message to be dismissed when ADSP compliance is
enforced. Acceptance of messages with invalid signatures from mailing
lists or those that appear to have been "converted" from a different
transport could be fairly typical when the ADSP assertion is CLOSED,
however these messages would not bypass other typical message
screenings. Scoring or annotation for CLOSED assertion messages with
invalid signatures is also likely to place these messages into a
different recognizable category that improves the quality of the
screening process.
Thus if we do as you proposes (which seems to be to omit the domain
existence check) then there will be no point whatsoever in deploying
ADSP at all. However, it seems that the consensus is that such a
check is essential (there is room for discussion for its details),
and hence your idea is already rejected by this WG - unless you can
come up with a way of avoiding this problem.
A domain existence check is independent of ADSP or DKIM. Such checks
are better devised by an SMTP specific WG since such limitations will
impact interoperability with SMTP independent of DKIM or ADSP. As
such, if there is to be some type of check, this check should be
defined in a different draft by a specific SMTP WG. In the mean time,
at least the ADSP assertion of LOCKED offers a level of protection for
a specific domain.
... The assertion would be silent as to whether NNTP might employ
DKIM, for example.
It [has] nothing to do with whether NNTP employs DKIM. If someone
writes a Usenet with article (unsigned) with From:
someone(_at_)foo(_dot_)remove-this-when-replying(_dot_)com
(which is quite a common practice to avoid scraping of the address
by spammers), and if that messages is subsequently gatewayed into
email (again a fairly common practice), then a vigilant email
Verifier is likely to discard it. I see no way to avoid that, and it
is the price we have to pay for better security in the email world.
To ensure ignored domains do not offer a method to spoof addresses,
defining which recognizable domains should be ignored must be
accomplished. Again, such definitions should be done in a different
draft since this has nothing to do with DKIM or ADSP.
As a slight amelioration of that position, i mungers could be
persuaded to write their From addresses as From:
someone(_at_)foo(_dot_)remove-this-when-replying(_dot_)com(_dot_)invalid
(which I would regard as best practice anyway), then verifiers
might be permitted to pass that case.
Agreed, and such a domain is defined in RFC2606. However RFC2606
appears to be in need of updating. Just a definition of which domains
should be ignored represents a significant level of work not done
quickly and not by the DKIM WG.
Discerning whether a message was "intended" to be carried by SMTP
remains a problem for receivers.
Indeed. But if you cannot provide a method for such discernment,
then we are forced to assume that they _were_ so intended, otherwise
ADSP is useless.
Disagree. Different handling is determined by ADSP assertions.
LOCKED ADSP protects a domain issuing transactional messages placed
into specific folders by recipients. Full protection might depend
upon recipients using tools they already have at their disposal.
Folder placement will not risk introducing a scheme that could become
a means to instigate DDoS attacks.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html