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