On November 9, 2005 at 20:42, Scott Kitterman wrote:
No matter what you do with hueristics, you are only modulating an approach
that will only ever be so good. What we need is more deterministic solutions
and less dependence on heuristics.
I think most will agree with this, but such solutions must be weighed
against the risk of legitimate email practices. As I view SSP now,
it will only have any real use for select domains where restrictive
email policies is justified, but for most email users, SSP (as it is
currently defined) will provide little to no benefit for rfc2822.From
protection.
Email service providers will have to publish relaxed policies to
avoid the problems of restricting From to matching the signer domain.
In this case, SSP is only used to indicate if the provider signs or
does not sign messages versus providing any rfc2822.From protection.
I may well have to set up a sub-domain for list traffic. It would be a minor
inconvenience. As you can see by the From address I use on this list, I
already set up dedicated From addresses for mailing lists. I already deliver
these into a separate mail box. Adding a sub-domain for it would be a one
time 10 minute job. It's not something I'm particularly concerned about.
Is setting up a sub-domain a simple administrative job for large
email service providers and other large organization? Also, since
the sub-domain will require relaxed policies on the From, attackers
will just switch to the sub-domain versus the primary domain for
From-based spoofing.
To many end-users, I do not think they see much difference in
sub.example.com and example.com. To them, the mail is from
"example.com".
Additionally, if there isn't a general solution to the DKIM/Mailing List
incompatability, then I expect that receivers that want to receive mail from
mailing lists will white list lists that they subscribe to and no reject
messages that are outside the domain's SSP from those lists. Yes, it's more
administrative burden, but it's a one time burden per list that can be
reasonably well automated.
Not sure about your conclusion about the ease of this. This now
requires MUA-based interaction (or end-user interaction) which seems
to be something that many are trying to avoid.
Also, from a verification perspective, the MTA must now examine
per-user preferences. I.e. A DKIM "failure" may never be able
to indicate out-right rejection since per-user preferences must
be examined. Such checks may be doable for larger organizations,
but burdensome for smaller organizations. It ignores the usability
factors to end-users specifying such preferences and the added
burden of subscribing to a list and remembering to "whitelist" it.
What about the cases where lists change domains?
--ewh
_______________________________________________
ietf-dkim mailing list
http://dkim.org