Douglas Otis wrote:
Of course other identifiers can be assessed. This statement
however indicates assessments associated with the signing
domain can not include elements of the message envelope.
Okay, but it's IMO unnecessary to talk about it in Jim's draft.
He has it already in 1.2:
| The transmission of messages via SMTP, defined in RFC 2821,
| and such elements as the envelope-from and envelope-to
| addresses and the HELO domain are not relevant to DKIM
| verification. This is an intentional decision made to allow
[...]
End of story as far as I'm concerned, no need to reiterate it.
A verified signature is independent of the message envelope
parameters. Unless the signing-domain is assessed separately,
a bad actor could easily ruin the reputation of a signing
domain. This can not be permitted!
Of course it's "permitted", receivers and future reputation
services are free to do whatever they like including stupid
things. We can't enumerate all potentially bad ideas, it's
hard enough to catch some necessarily bad ideas.
The exercise should ensure a signing domain can retain their
trustworthy status despite the mischief of bad actors.
If it's your intention to get another "I'm no spammer" scheme
without chance that it could be used for the opposite effect
it won't fly. Something signed by a big ISP will never have
the same reputation as something signed by a bank.
And Jim's draft can't be a "how to" for reputation services,
officially that's off topic, declared to be out of scope in
the WG charter. Better stop it before it gets out of hand,
or we're trapped in (un)foreseen ratholes.
That would allow a bad actor a simple means to destroy
reputations for signing domains. Tilt- Game Over.
There's a chapter about "replay attacks", all we can do is
warn receivers / reputation services to get ready for this.
And another chapter about zombies "within" an organization:
If those zombies destroy the reputation of a signing domain
that's precisely what we want: Either they get rid of the
zombies, or they get the deserved reputation.
the signing domain MUST NOT be held accountable for a
problematic instance of a message.
Signing domains are accountable for allowing the transmission
of a message, and the only interesting case are "problematic"
messages, otherwise nobody cares. There is no 2119 MUST NOT,
receivers will say "stop this enlargement spam or else". Or
phishing / mailbombing / etc.
The signing domain marking a message as trustworthy is
assuring the recipient the message is not deceptive in
_some_ fashion.
Where "some" is either undefined or essentially the same as
"I was stupid enough to transmit this mail, sorry if it's
not exactly what you want".
Violate the trust, lose the endorsement. Let it happen too
often, the signing domain will also lose their trustworthy
status.
Yes. I'd hope that a "reputation service" offers more than
black and white, but also several kinds of grey in between.
Why convey an indication of trustworthiness for messages
from bad actors? Unless the domain is known, it should not
be assumed to be trustworthy.
Domains like spamcast are known. For ISPs with 1,000,000 or
more customers it's only natural that one (?) of them tries
to start a new career as baby-spammer, daily. Not counting
the zombies, discussed in another chapter of Jim's draft.
A reputation system will be unable to respond fast enough
to deter abuse of a "trusted" message status.
Not necessarily.
As you have already indicated, there is no simple system for
assessing a violation of trust based upon DKIM signed
messages. Many phishing attacks start and finish within
hours, and there are thousands of domain names that can be
used for this activity.
When I wrote "not necessarily" what I had in mind was Ironport
with their combination of Senderbase and SpamCop.
The MSA signs, not the laptop.
The MSA or perhaps the MUA, from my understanding, can sign
messages.
Okay, the latter is new for me, but let's say it's possible.
Then I fail to see why a mobile MUA should be necessarily
more dangerous than other MUAs. Anything with a Win-logo on
it is threatened, whereever it is. All they need is a say
Sony CD and "oops, did it again".
few domains can fully trust all users with access to their
outbound servers.
Then let them partition their users in signing subdomains,
or let them use different subdomains for groups of similar
AUTH methods. It's their problem. If you want the aspect
of different classes of users / AUTH methods as new chapter
it's okay, but I'm not yet convinced by your "flag" idea.
Bye, Frank
_______________________________________________
ietf-dkim mailing list
http://dkim.org