[ietf-dkim] Replay isn't the problem, spam is the problem
hsantos at santronics.com
Thu Aug 11 17:52:20 PDT 2005
----- Original Message -----
From: "Michael Thomas" <mike at mtcc.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
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
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.
More information about the ietf-dkim