ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Replay isn't the problem, spam is the problem

2005-08-11 18:09:14

----- Original Message -----
From: "Michael Thomas" <mike(_at_)mtcc(_dot_)com>



Amir Herzberg wrote:
Replay protection allows automated reputation management  [...]

The last I checked, reputation wasn't in scope of the current
charter. There didn't seem to be much controversy about that.
I'd suggest that unless there is some threat about so-called
replays that affects with the current scope of work, that
we defer these discussions until reputation is in scope.


But reputation or no reputation concept, the problem is that 3rd party
Replay "Operators" AKA Mailing List Servers can create more spam issues
under the disguise of a DKIM validated messages.

In addition, 3rd party replay operations can change the current practice of
people using a domain on a replay server (i.e, subscribing to a mailing
list).

It is quite possible End-users with DKIM verifiers (either at their MDA or
MUA) might invalidate the 3rd party signing.  I have control over my own
copy reception since I can white list the "known" sender, but I have no
control over how other DKIM verifiers will behave.

In other words, I might have to create a special domain just to join a
mailing list.

The only way around this is to:

 - Relax my SSP policy to allow 3rd party signing, or
 - use a different domain, or
 - not use DKIM at all, or
 - have some other way of validating the sender.

In all cases, if a DOMAIN has an exclusive policy, reputation or not, the
3rd party SIGNER can not use this DOMAIN for the OA since the transaction
might be not validated at the member edge.

Is this not correct?

How do you get around this?

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com


_______________________________________________
ietf-dkim mailing list
ietf-dkim(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/ietf-dkim