On Sat, 2005-11-26 at 10:50 +0100, Frank Ellermann wrote: > Douglas Otis wrote: > > > Sending messages where the From header field indicates the > > message's author is not exploiting or abusing the domain of > > the author's email-address. > > In that case you have a Sender or Resent-* header field with > a "Purported Responsible Address", or it's a mailing list, or > something behind a news2mail (or similar) gateway, or it's a > submission to the moderators of a newsgroup. > > That's a complete enumeration of all "allowed" possibilities, > isn't it? Please add any missing special cases.
In the case where a signature is added, other headers are not needed to establish an accountable entity. When there is no signature, then a binding-assertion from a prior correspondence, or a problematic authorization, could establish an expectation that a signature should be present. In the case of SSP, the >From header must be used to ensure a "visible" selection, whereas binding-assertions would permit greater flexibility and offer improved safety. There is the case where a small business or individual relies upon an access provider to send their outgoing email, in addition to the problems created for other types of services. Mustang Sally <[EMAIL PROTECTED]> sent via the access provider may be signed: 'd=some-access-provider.com' Adding a Sender header changes the appearance of the message and creates support calls asking why is the damn Sender header being misused? > > This SSP approach retreats to a point in time where there > > were but a few TLDs and just one character-set. > > Let's ignore IMA / IEE for the moment, that won't fly in 2006, > and they'll offer some IMA-to-282[12] mechanism. Could you explain this? > > An authorization scheme like SSP opens the door for unfair > > coercion, which shift the burden onto an often hapless > > email-address domain owner. > > It's fair if they know what they are doing with their "PRA", > and what they can't do with it after they bound it to a SSP. Problems of coercion supplants a semblance of fairness. The SSP is limited to only the "visible" From header and has nothing to do with a PRA algorithm isolating a last-hop server. A signature does not depend upon the last-hop, making the PRA algorithm inappropriate. > Worst case, it won't work with some mailing lists / newsgroups. > If they know this they'll stay away from these lists / groups. > That's not "unfair", it's simply that you can't have your cake > and eat it too. A binding-assertion removes risk of coercion to retain an option that allows current practices. An authorization may become a requisite for better handling, as already seen in other authorization schemes. The next form of coercion is a bit more insidious, but is also already in place. Based upon a derived authorization, reputation may then accrue upon the email-address domain. The SSP draft reports problems to the email- address domain, rather than the signing-domain, for example. This unfair use of reputation means strict authorization that prohibits all third-party signing becomes the only "de facto" option available. This "de facto" option breaks current practices. SSP takes away freedom and exposes greater amounts of personal information. The illusory permissive authorizations only act as bait for the unfair reputation trap. Of course, there will be endless bells and whistles added, as with other authorization schemes, irrespective of the related overhead. > > SSP authorization is _not_ the only option that DKIM enables. > > For some here it's an important DKIM feature, while finding a > reliable abuse-address is only secondary. Maybe that will > change in the future if the whole world agrees to reject mail > from "unregistered" sources. But we're not yet there. This expresses wishful thinking that abusers will be deterred by the simplistic, yet disruptive, matching scheme. Any indications, good or bad, related to SSP exposes recipients to greater risks. SSP will likely _increase_ the success rate of spoofing. > > However, SSP makes things worse. > > You're not forced to use SSP if you don't like it. I don't > intend to use any 2822-scheme (SSP or PRA), if that limits my > freedom to use "my" address in a mail or news header whereever > it pleases it me. But others have different priorities, and > nothing's wrong with that. There is choice until a large provider desires to downgrade the handling of messages without authorization, and perhaps simply delete them without a DSN. Sound familiar? Jim Fenton already suggested some justification in this regard, as there is no practical anti-replay abuse mechanism in DKIM. > Let's just make sure that the offered solution is no nonsense > and no obscured "FUSSP" working only after the whole world > adopted DKIM. Indeed much of the rhetoric offers justification for DKIM based upon an authorization scheme, while ignoring the continuation of the same problems and the disruption that is created. Authorization techniques have already demonstrated a lack of fairness with respect to reputation accrual. Adding binding-advice or binding- assertions within the signature can be be readily cached, and offers safer protections while avoiding a disruption in practices, coercion, and unfair treatment. -Doug _______________________________________________ ietf-dkim mailing list http://dkim.org
