On Feb 22, 2006, at 7:52 PM, John Levine wrote:
the Tagging standard could be used to define a standard way to
include reputation data in e-mail headers
Maybe I'm dense, but why would anyone care about alleged reputation
data that a sender included in his own headers? It only makes
sense for recipients to check reputations of incoming mail.
The tag would not be the sender indicating that they have a good
reputation. Rather the tag would indicate whether the source of the
message from within their domain is trustworthy. A DKIM based
reputation will be expensive and perilous. As the DKIM signature
does not encompass the envelope, evaluation must first discard the
envelope when considering the reputation of the signing-domain. DKIM
related bad acts are therefore limited to message content, such as
malware, forged headers, or dangerously misleading links and
information.
Use of DKIM will evolve into marking messages from trusted domains.
Cisco already does this internally, and there are several companies
following suit. Users are not expected to recognize email-
addresses. The problem many domains have is not all users with
access are trustworthy. Perhaps this domain would like messages from
their administrator marked as trustworthy, but would never wish this
mark added to just any of their signed messages. Tagging the DKIM
key would be one method to impose selective message trust-marks.
Perhaps financial institutions improve security and not have temp
workers messages receive a trust-mark, while still signing all their
messages to ease filtering efforts.
The vast amount of email will be from users that normally would not
be considered trustworthy. Only seeing a smaller percentage of
message marked as trustworthy by the sender reduces the overhead
needed to evaluate violations of trust (based solely upon the message
content). IP block-lists will still handle the majority of abuse,
but DKIM can be used to produce a vetted list of trustworthy domain
names. Messages not marked with a tag as trustworthy by the signing-
domain can be ignored by the DKIM trust vetting process. The major
effort remaining would be to ensure bad actors can not corrupt the
trusted list data-base, and that it can be defended.
A secondary concern would be message replay abuse, which is why the
envelope is discarded.
Guarding against message replay abuse may require a secondary
qualification of the message. Sender-ID or HELO verification could
qualify the message as not replay abuse. In some cases, the return-
path with SPF could also provide this secondary qualification. None
of these schemes work beyond a mediator however. One method that
could be used to deal with messages without a secondary qualification
would be to delay acceptance.
While Sender-ID and SPF require the listing of all the IP addresses
used by their domain, the HELO only needs to return the IP addresses
for the immediate MTA. HELO verification can be assured in one DNS
lookup, whereas SPF/Sender-ID may require more than one hundred. The
delayed acceptance practice can be avoided in most cases by ensuring
the HELO can be verified and can be associated with the signing-
domain. Forward reference PTR records that return an RRset of
associated HELO domains would allow more domains and machines to be
associated than possible with SPF/Sender-ID, while introducing only
one additional lookup. This HELO list strategy could qualify any
message related domain such as the DKIM signing-domain, the return-
path, or any other email-address domain.
-Doug
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg