ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Re: dkim.org (mipassoc.org/dkim) web page updated

2005-11-09 18:48:01
On 11/09/2005 11:15, Douglas Otis wrote:
On Mon, 7 Nov 2005 19:01:40 -0800 Douglas Otis 
<dotis(_at_)mail-abuse(_dot_)org>

wrote:
DKIM without SSP provides an ability for Name-based white-listing of
transports.  Name-based white-listing/reputation would not be prone
to IP address exploits.  Filtering programs would have a verifiable
source for a message to permit a significant reduction in related
errors.  If there was abuse, there would be a verified name for
addressing complaints.  Why would that be useless for you?

For reputation systems, I've little interest.  I'm a very small business
and so the type of large scale systems you've described as being
necessary for rapid/effective reputation are out of reach.  Honestly
Spamassassin does well enough for me and it's not clear segregating
reputation into a separate set of heuristics will produce a more reliable
end result.  So, in
short I doubt more heuristics will make things better and I can't afford
them anyway.

A verified signer for the message could improve the results of filtering
applications like Spamassassin.  As this is your primary mechanism,
improving these applications would benefit you significantly. A general
requirement that From matches the signer will not be reduce the amount of
spam, as spammers adapt.

You keep saying that.  I don't believe you.

A verified identity is useful for whitelisting.  I manage that well enough 
already, so it's not a problem I need help solving.

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.

What major benefit do you expect?

I assume DKIM is going to happen one way or another.  So, SSP would
provide
a deterministic way for mail receivers to reject certain messages.  This
will help me defend the reputation of my domains.  It will also perhaps
provide some reduction in the risk that my domains' users will get
phished (none of them use an MUA that only displays the pretty name).

Mandating From be tied to the signer will be highly problematic for most.
Domains seeing significant spoofing may accept this restriction.  Without
restricting the From to the signer as a general practice, then your
assumptions would be wrong.  For example, I would assume you want your
messages seen coming from a list-server.

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.

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.

Ensuring the signer is able to control abuse of the signature does not
detract from the benefits that you would enjoy, but it does allow the use
of a name-based reputation.  The self-revocation mechanism that has been
suggested would also benefit those that do not use a reputation service.
These self revocations would be driven by reputation feedback.  This would
be a way to share the benefits of reputation. : )

It sounds like you are saying that I'll be able to self-revoke based on 
results from a reputation service that I don't use.  I don't think this is 
any more sensible than the rest of what you are proposing.

Getting SSP right would be of much greater value to me that going off on the 
tangent that you propose.

Scott K
_______________________________________________
ietf-dkim mailing list
http://dkim.org