Subject: Re: [ietf-dkim] Collection of use cases for SSP requirements

From: Scott Kitterman <[email-masked]>
Date: Wed, 08 Nov 2006 11:40 -0500

On Wed, 8 Nov 2006 07:55:15 -0800 Steve Atkins <[email-masked]> wrote:
>
>On Nov 8, 2006, at 4:24 AM, Charles Lindsey wrote:
>
>> On Wed, 08 Nov 2006 04:46:08 -0000, wayne <[email-masked]> wrote:
>>
>>> In  
>>> <[email-masked]>  
>>> "Patrick Peterson" <[email-masked]> writes:
>>>
>>>> - I sign all email AND have enough confidence in the reliability of
>>>> signatures AND the risk of allowing spoofed email is high enough  
>>>> that I
>>>> choose to accept the risk and therefore state that receivers  
>>>> should drop
>>>> unsigned/invalid signature email.
>>>
>>> OK, as a receiver, can I blame the sender for any problems with
>>> legitimate email being rejected due to DKIM failures?  If a receiver
>>> can't transfer the blame to the sender, why should the receiver treat
>>> this any different than just being suspicious?
>>
>> I think some site like a Bank, that is heavily phished, might go so  
>> far as to declare
>>    "I sign all mail. Please delete/reject/drop/whatever (perhaps  
>> even silently)
>>     all messages that fail to verify".
>>
>> That site would have to be pretty confident that the genuine mail  
>> it sent out was 100% clean, but it might well decide that it was a  
>> lesser risk to have some genuine messages dropped than to let  
>> phishes go through.
>>
>> BTW, are there any plams to have keywords for some of the various  
>> policies that might be declared, so that verifiers (or rather their  
>> policy modules) could recognize them and adjust their policy  
>> accordingly)?
>
>I do have to point out that SSP will not affect phish emails noticeably,
>after a very short transition period.
>
>So if a bank were to do this it would mean 1) phishing mails won't
>be affected and 2) legitimate mail from the bank is likely to be
>affected.
>
>So... what's the _real_ use case, again?

Please explain.  If a sender publishes a policy that says I sign all mail 
and a receiver rejects, deletes, etc. all mail that isn't signed by that 
sender, what is the phisher's transition path to work around it?

I agree that this does not help with look-alike domains, but for phishing 
that uses a sender's domain, I'm noy sure what you are getting at?

Scott K
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: John Levine <[email-masked]>
Date: 9 Nov 2006 07:34:31 -0000

>Please explain.  If a sender publishes a policy that says I sign all
>mail and a receiver rejects, deletes, etc. all mail that isn't signed
>by that sender, what is the phisher's transition path to work around
>it?

He uses another domain in his return address, like Steve said.  You
may carefully look at the return address in your mail, but most people
don't, and even if they do, bank marketing departments are unable to
resist the urge to invent a new domain for every new ad campaign so it
doesn't tell you much if you don't recoginize the domain.  (Quick, who
is applyonlinenow.com?)

I already get a whole lot of phish for Paypal that doesn't have a
paypal.com return address, ditto for a lot of the bank phish I get.  I
see no reason that is going to change.

If there were a way to look up a domain and get back a response that
tells you whether it's a bank, that would be useful.  But SSP doesn't
do that.

R's,
John

---

From: Graham Murray <[email-masked]>
Date: Thu, 09 Nov 2006 09:06:35 +0000

> doesn't tell you much if you don't recoginize the domain.  (Quick, who

And in doing that they are their own worst enemies. Everyone must
agree that phishing is a problem at the moment. The banks are, IMHO,
being very irresponsible by a) Not ensuring that all email they send
comes from a single identifiable and publicised domain (or a
sub-domain thereof) and b) Using third party mail services to send
mail shots on their behalf.

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 09 Nov 2006 17:21:38 +0100

John Levine wrote:
 
> I already get a whole lot of phish for Paypal that doesn't have
> a paypal.com return address

Maybe the opposition is intimidated by Paypal's SOFTFAIL, sooner
or later they (= the bad actors) will check out what happens if
they ignore it.  Interesting times also for the phishers, they
can try to ignore all combinations of defense mechanisms, or they
start to target their "audience" depending on what they learned 
about the actually used defenses per receiving domain.

Frank