On 5/28/10 9:24 AM, Alessandro Vesely wrote:
I agree ADSP currently leaves much to be desired. It deserves
completion. (DKIM itself is in a similar situation, since it is still
not MIME-compliant. A somewhat embarrassing circumstance for a
protocol designed not to "break forwarding".)
Major providers such as AOL had insisted on breaking MIME, and S/MIME.
This has changed, where more of their users access email by the web, as
the era of modem squeals and "You've got mail." fades. However,
provisions allowing modifications can be exploited.
Had DKIM's canonicalization recognized MIME, then enumerating MIME
sections could have been less problematic than line counting. Such a
change to DKIM remains possible, where damage by comments added by
forwarding services can still be remedied with reliance upon their
Authentication-Results headers. Ideally, only this header would be
added along with it being universally understood by mail clients. Until
then, things will break.
At any rate, let me note that besides countering phishing, ADSP plays
a possibly more foundational role: it/characterizes/ DKIM signatures.
Thus, there may be further *DSPs, e.g.
* list signature, tied to the signed List-ID,
* forwarder signature, tied to an SPF-validated 5321.mfrom.
I'd be interested in adding an experimental option for DKIM able to
process a sender's instruction of which domains should be granted
exceptions. I'd be reluctant to restrict which verification methods
should be used, only what items should be available for such.
If there is a concern about using of DNAME, a new label could be defined
that permits third-party delegation with a CNAME. This method would
still leave the phished domains in control, and allow them to react to
reported problems. As it is now, there is little they can do when a
problem occurs.
These characterizations integrate assessments. By qualifying the
reasons why a given party signs a message, they give an insight into
the mail transmission process, which may lead to the possibility of
tuning it, e.g. by routing feedback appropriately. OTOH, unqualified
signatures only entrust limited responsibility, as they don't say what
questions the signer should be able to respond to. In this respect, an
hypothetical reputation system that allowed to compute a message's
worthiness up to 16 digits of precision, albeit useful, wouldn't
differ much from spamassassin's fuzzy approach.
This might sound a bit strange, but reputation systems are primarily
concerned with spam in general. Sender authorization for ADSP
exceptions (LDSP as it might be described) is likely the only input that
could safely allow exceptions.
-Doug
Side note:
Although the Authentication-Results header is new, it suffers from a
security weakness as well. The IP address seen at border MTAs when
receiving public messages (those unauthenticated over port 25) is not
normally captured. Only authenticated messages should exclude this
information. In an era where compromised systems are the predominate
source of spam, this missing information is often the only identifier
able to locate problematic sources. People should not view this as a
privacy issue, but instead see the greater concern being whether their
system is compromised and is directly distributing spam. Bots and rats
(remote access trojans) do nefarious things well beyond spamming, like
key-logging and spoofing account details from your bank. The related
criminal enterprise is growing, with their outward presence becoming
less obvious. Ever since XP SP3, there is 10MB of boot space that is
able to hide all types of VM. :^(
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html