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

From: "Patrick Peterson" <[email-masked]>
Date: Mon, 6 Nov 2006 23:18:24 -0800

3 months and 1300 mailing list posts ago, I wrote that I was going to
survey some senders on SSP use cases and report results back to the
list. At long last, here are the results.

We reached out to a large set of senders who are either heavily phished
or have very valuable online brands they want to protect. Our results
are therefore highly biased toward these organizations. They send high
volumes of legitimate email using heavily phished domains. They will be
among the earliest enterprises to deploy with aggressive SSP policies.
All of these senders understand the inherent limitations in
authenticating a domain used in email (cousin domains, friendly names,
lack of client support, etc). They understand DKIM is not a 'silver
bullet' solution but still believe DKIM offers a technology that over
time will help reduce their current problems of domain spoofing.

Developing SSP is very different from developing DKIM. DKIM is a
technical challenge while the challenge of SSP is primarily to determine
what senders want to communicate to receivers and what receivers want to
know about senders policies/practices. SSP should provide a vocabulary
to senders that meets their needs and is useful to receivers -- this is
the most important requirement imho. Separation of SSP Requirements from
SSP is very helpful.

Here is their feedback. I have also requested that they join the list
and provide direct input. This is *requirements* input, not proposing a
solution. And if anyone attended the recent MAAWG conference in Toronto,
this is the same information I presented to ISPs.

Requirement #1. More aggressive practice options
Senders are concerned the current options aren't aggressive enough to
cause change in how spoofed email is handled. Without such a change
implementing DKIM is of little value to them.

The senders want to stop domain spoofing from impacting their brand and
customers. They want more aggressive policy statements that will more
aggressively encourage the receiver to drop spoofed email. It may be
some time before they are 100% signing and common errors that cause
signature failure for their mail are eliminated but they are focused on
realizing this as soon as possible. When this happens, they want to be
able to request that receivers drop signature failures or unsigned
email. For some, the cost of phishing is so high and some day the risk
of dropping messages will be so low that their inability to state a
stronger policy will impact their ability to reduce the impact of domain
spoofing.

Another way to state this requirement is that there is a difference
between, 
- I sign all email, and
- I sign all email, treat unsigned or invalid signature with suspicion,
and,
- 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.

Requirement #2. I send no email.
Many senders have a large number of domains that are never used in
email. They want to be able to state this unambiguously. To the senders
I surveyed, the 'I send no email' policy is a unique case from the other
cases. I asked if they wanted this in addition to the SPF/SIDF '-all'
policy and they universally said yes. 

Requirement #3. Feedback of invalid signature/unsigned mail
Senders are concerned that the #1 item that will prevent them from
moving to aggressive practices is the inability to identify errors.
Errors on their part (failure to implement signing, improper signing),
receiver errors (noncompliant implementations of DKIM validation) or
anything else that Murphy's Law says will happen. They would like a
feedback mechanism to be defined that provides this feedback. Defining
this mechanism does not require it to be implemented by any receiver;
failing to define this mechanism makes it impossible to implement easily
for anyone. (Without going too far down the solution avenue, senders
felt one possible solution to receiving an excessive number of
invalid/unsigned feedback emails during a large-scale spoofing attack
was to state that they only wanted feedback for emails which originated
from their IP space as defined by their SPF record. Not a complete
solution as envelope sender not equal From: and mailing list traffic
doesn't originate from their IP space, but many felt this might be a
good compromise solution.)

Please consider these inputs and (hopefully) look for more direct input
shortly. I hope these SSP requirements are useful for the SSP
Requirements doc. I am unable to attend the IETF session today but I'm
sure it will be a lively discussion.

I've excerpted the most relevant sections from SSP Requirements and SSP
below with some edits to be more specific about possible changes.
Changes prepended with >>>>

http://www.dkim.org/specs/draft-ietf-dkim-ssp-requirements-02.html

4.1.  Problem Scenario 1: All Mail Signed with DKIM
<snip>
   3. A provides information that it signs all outgoing mail, but places
no expectation on whether it will arrive with an intact signature.
   4. B could use this information to bias its filters such that it
looks somewhat more suspicious.
>>> This is great for senders that sign their email but don't have
confidence of high rate of receiver validation or that aren't too
concerned with domain spoofing.

4.2.  Problem Scenario 2: Illegitimate Domain Name Use
<snip>
   3. A provides information that it signs all outgoing mail, but places
an expectation that it should arrive with an intact signature, and that
the receiver should be suspicious if it does not.
   4. B could use this information to bias its filters such that it
looks much more suspicious.
>>>> A set of senders really want B to drop this email. Giving them to
vocabulary to state this is their desire. ISPs are of course free to do
as they see fit, but providing them with more granular information is
useful.

4.3.  Problem Scenario 3: Domain Sends No Mail
A domain may not intend to send mail at all. In such a case, it could be
advantageous for a receiver to know the domain's intent and would be
likely to treat such mail very suspiciously.
>>>> Option to state "drop" vs "very suspiciously" desired.

6.3.  Practice and Expectation Requirements
<snip>
9. Practices and Expectations MUST be presented as an information
service from the signing domain to be consumed as an added factor to the
receiver's local policy. In particular, a Practice or Expectation MUST
NOT mandate any disposition stance on the receiver.
>>>> It's possible to state a desired disposition (drop) without
mandating a disposition stance. An ambiguous expectation and a binary
expectation is different from an expectation and a mandate.

http://www.dkim.org/specs/draft-allman-dkim-ssp-02.txt

4.2.  Record Syntax
<snip>
   p= Outbound signing practices for the entity (plain-text; OPTIONAL,
      default is "unknown").  Possible values are as follows:

      unknown  The entity may sign some or all email.

      all  All mail from the entity is signed; unsigned email MUST be
         considered Suspicious.  The entity may send messages through
         agents that may modify and re-sign messages, so email signed
         with a Verifier Acceptable Third-Party Signature SHOULD be
         considered non-Suspicious.

      strict  All mail from the entity is signed; messages lacking a
         valid Originator Signature MUST be considered Suspicious.  The
         entity does not expect to send messages through agents that may
         modify and re-sign messages.
>>>> Notch above 'Suspicious' desired

            NON-NORMATIVE RATIONALE:  Strict practices may be used by
            entities which send only transactional email to individual
            addresses and which are willing to accept the consequence of
            having some mail which is re-signed appear suspicious in
            return for additional control over their addresses.  Strict
            practices may also be used by entities which do not send
            (and therefore do not sign) any email.
>>>> Strict signing not equal to 'does not sign' use case to many
senders.

pat

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

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 7 Nov 2006 21:08:12 -0500

Thank you for pulling that together.  I think that was an excellent writeup.

One point I'd like to pull the thread on is the word drop.  Rather that drop, 
I think it would be better to say reject.  I'm taking the word drop to mean 
delete here.

I think that deleting messages that fail an SSP test is not good for the 
overall reliability of the e-mail ecosphere as there is no indication to 
either the sender or the receiver (at the user level) that a message has not 
been delivered.  This raises uncertainty.  If messages are rejected (SMTP 550 
at the end of DATA), then legitimate senders will be notified of the failure 
and can take action to rectify the problem without the backscatter risk 
associated with accept then bounce.

I think that rejecting messages meets the goal that is stated here without 
adding risk or uncertainty.

Scott K

---

From: "Powers, Jot" <[email-masked]>
Date: Tue, 07 Nov 2006 20:07:41 -0700

On 11/7/06 7:08 PM, "Scott Kitterman" <[email-masked]> scribbled:

Just joining, so excuse me if this has been dealt with before.

> associated with accept then bounce.

I think we agree 100%, if we can get the rejection to happen at the end of
data, and not after delivery.  After delivery, the results of "joe jobbing"
are simply too onerous.

> adding risk or uncertainty.

We agree, if we can get that data phase rejection.  The problem that I see
is that most systems aren't setup to do that, and aren't willing to take on
the complexity of "mostly" accecpting before rejecting.

As an admin at a large (non-spam) email site, that is, to put it mildly,
heavily phished, we would rather email that is not DK signed be dropped (ie
silently deleted) than "rejected" if my statements about rejection after
data are true.

-Jot
-- 
Jot Powers             <[email-masked]>
Skype: jotebay

"Trimming quoted text in email leaves more room for you in heaven."
   -Ricardo Signes in irc://irc.perl.org/#perl

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 7 Nov 2006 22:59:49 -0500

> > I think that rejecting messages meets the goal that is stated here
> > without adding risk or uncertainty.
>

This may be what you meant, but it's my understanding that you have to accept 
the entire message and respond 550 to the final '.'.

There are timing issues associated with doing CPU intensive processing before 
queing the message that would have to be managed.  Is that where you see the 
complexity?

> silently deleted) than "rejected" if my statements about rejection after

I can understand that.  

I think that reject or deliver (if only to a spam folder) is a reasonable 
approach.  Deleted might not be a bad fallback if rejection doesn't work out 
for some reason for some receivers.

I do know that there are large commercial receivers that are doing tasks more 
CPU Intensive than DKIM verification (e.g. virus scanning) during the SMTP 
session and doing it reliably, so I believe that while reject after DATA does 
have challenges, I think they are manageable.

Scott K

---

From: wayne <[email-masked]>
Date: Tue, 07 Nov 2006 22:21:27 -0600

In <[email-masked]> "Powers, Jot" <[email-masked]> writes:

> data, and not after delivery.

Yes, rejection during the SMTP session is *MUCH* better.

>                                After delivery, the results of "joe jobbing"
> are simply too onerous.

You are reasonably safe in sending a bounce after the SMTP session
ends if you have gotten an SPF Pass or if you get both a DKIM Pass and
the 2822.From: matches 2821.MAILFROM.

-wayne

---

From: wayne <[email-masked]>
Date: Tue, 07 Nov 2006 22:46:08 -0600

> list. At long last, here are the results.

Thanks for taking the time to do this.  I, for one, appreciate it.

It would also be useful to get similar insight from receivers.

> [ ... ]             while the challenge of SSP is primarily to determine
> the most important requirement imho.

I completely agree with this.  SSP has to be useful for both senders
and receivers and it is all about communication.  You can't dictate
what receivers do, but many receivers *are* interested in hearing what
senders have to say and will take appropriate actions if what the
senders say will benefit them.

> - I sign all email, treat unsigned or invalid signature with suspicion,

Can you please explain the difference between the above two?  Are you
saying the first one is really "I sign all email, but don't treat DKIM
failures as suspicious"?  Or, maybe the question is better phrased,
what is the difference between that and just an "I sign some email"?  

> 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?

Mind you, I've argued for this option as being potentially useful.  A
sender that discovers that someone is munging their email has options
such as sending with a different subdomain that just says "I sign
some", or working with the receiver to fix the problems, or telling
the receiver they have to change email addresses, etc.

> policy and they universally said yes. 

Can you explain more about why people want an SSP which says "I send
no email" rather than just having an SPF record of "v=spf1 -all"?

A while back, I changed my opinion on this and I now think that both
are useful.  The SPF record covers the 2821.HELO and 2821.MAILFROM,
while SSP covers the 2821.From:.  These are all different and there
are cases where a domain can end up in the 2821 identities, but should
never show up in the 2822 identities and vice versa.

-wayne

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 08 Nov 2006 12:24:44 -0000

On Wed, 08 Nov 2006 04:46:08 -0000, wayne <[email-masked]> wrote:

> In <[email-masked]>  
> "Patrick Peterson" <[email-masked]> writes:
>

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)?

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Powers, Jot" <[email-masked]>
Date: Wed, 08 Nov 2006 08:02:03 -0700

> queing the message that would have to be managed.  Is that where you see the

Yes, although it's been a long time since I've managed a site that was
mostly incoming email, so I'm probably not up to date on what the large mail
providers have to deal with.

> for some reason for some receivers.

My thoughts are that I know what problems deferrals cause me on the sending
side (due to new public IPs that aren't whitelisted), I imagine the problem
would be worse on the receiving side if a rejection was guaranteed never to
be delivered (ie mail accepted, and *GASP* a forged from header :)  ).  In
that case I would expect a "reject, then delete" policy would be in the best
interests of the receivers.

> have challenges, I think they are manageable.

In my experience, I/O is more of the problem than CPU, but I'd love to hear
what the receivers say.

-Jot

---

From: Steve Atkins <[email-masked]>
Date: Wed, 8 Nov 2006 07:55:15 -0800

On Nov 8, 2006, at 4:24 AM, Charles Lindsey wrote:

>> In  
>> <[email-masked]>  
> 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)
> 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?

Cheers,
   Steve

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 08 Nov 2006 17:17:16 +0100

Powers, Jot wrote:

> I would expect a "reject, then delete" policy would be in the best

Yes, and also in your interest as admin of the domain phished.example

Scott's point "better reject" is about a legit sender with a simple
typo phished.example instead of phishes.example - however that sender
managed it, he's better off with a reject.  Otherwise his mails will
simply vanish into "drop" black holes, until he notes that something
in his 2822-From is very wrong.  Arguably a "false positive" from his
POV.  

If your sender signing policy expresses the wish to reject all mails
without valid signature receivers are still free to interpret this
less (= accept + tag as very suspicious) or more radically (= drop),
but ideally (wrt reliability) they'd reject it directly at their MX.

Frank

---

From: <[email-masked]>
Date: Wed, 8 Nov 2006 11:36:07 -0500

Example of "I send no email" 
I want to provide signing to 3rd parties. I will set up a signing.com
domain. signing.com will never send/initiate email and the owner of
signing.com wont have SPF in the house. So a receiver getting a message
purporting to be from signing.com can cheerfully drop the message

Thanks,

Bill Oxley 
Messaging Engineer 
Cox Communications, Inc. 
Alpharetta GA 
404-847-6397 
[email-masked] 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of wayne
Sent: Tuesday, November 07, 2006 11:46 PM
To: IETF DKIM WG
Subject: Re: [ietf-dkim] Collection of use cases for SSP requirements

-wayne

---

From: John Levine <[email-masked]>
Date: 8 Nov 2006 16:16:00 -0000

>silently) all messages that fail to verify".

Here's three cases:

a) paypal.com publishes that note.  So far so good.

b) mismanaged-isp.com publishes that note, and blames you when their
   users' poorly formatted mail disappears.  Not so good.

c) paypal-payments.com publishes that note.  I don't want their mail
   whether they verify or not.

It seems to me that the likely number of domains in case a), real
institutions with serious phish problems, is far smaller than the
number of b) and c).  I don't see how SSP can help me as a receiver
tell the useful info about a) domains from the useless info about b)
and c) domains.  I expect that people will be using third party lists
of a)'s, which makes me ask what the point of self-publishing this is.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Wed, 8 Nov 2006 09:54:55 -0800

On Nov 8, 2006, at 7:55 AM, Steve Atkins wrote:
>> 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".
>>
>> 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.

Validity and trustworthy assertions allow message annotation based  
upon either out-of-band trusted email-addresses or trusted domains.   
This annotation approach provides formidable protection against look- 
alike phishing.

See:
http://tools.ietf.org/wg/dkim/draft-otis-dkim-dosp-02.txt

> So... what's the _real_ use case, again?

The DOSP proposal solves several use cases:

DSN:
Validation of disparate rfc2821.MailFrom is accomplished within a  
single small DNS transaction.  This association is not prone to the  
many problems associated with address path registration.  Address  
path registration breaks with forwarding.  The size of a data-set  
needed for address path registration also leads to serious DDoS  
concerns.

Protect DKIM white-listing:
Validation of disparate SMTP clients is accomplished within a single  
small DNS transaction.  The association can utilize either address- 
literals or host names and assumes the EHLO has been validated prior  
to accepting the message.

Simplify provider designation:
A designation scheme can be accomplished within a single  
transaction.  This eliminates the need to exchange private keys,  
delegate DNS zones, or establish CNAMEs where the provider creates  
your private keys and only shares the public version.  These  
arrangements will be difficult to scale increasing cost and will  
likely lead to higher rates of invalid signatures due to  
configuration errors.  These arrangements will impede consumer's  
choice of providers.  A provider using their customers keys and  
domains also means forgoing valuable abuse feedback.

Anti-phishing:
Support annotation constructs that utilize the recipient's address- 
book or a list of trusted domain.

The different DNS checks (and even DKIM validation) should only be  
done when there is a direct benefit.  It remains doubtful that there  
is benefit hunting for policy that indicates a message should be  
signed.  The annotation strategy prevents such messages from spoofing  
recipients.

-Doug

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 8 Nov 2006 23:25:05 -0500

> of a)'s, which makes me ask what the point of self-publishing this is.
SSP can't slice toast either.  

A is good.  

B is not your fault.  No matter what you do, poorly configured senders will 
blame you.  They do it now, so this is no different than today.

C is not the problem SSP is meant to solve.

So it sounds to me like everything is fine.

Scott K

---

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

>A is good.  

Agreed.

>blame you.  They do it now, so this is no different than today.

Except that for those of us who want to make our users happy rather
than score points, we'll need to ignore the SSP from these guys.  So
if we need to do that, perhaps we should ignore SSP altogether and
pick up the relatively small set of A's some other way, as Steve A.
suggested.

>C is not the problem SSP is meant to solve.

Well, OK.  In one sentence, what IS problem that SSP is meant to
solve?  It would be helpful if your answer kept in mind that receivers
have no inherent interest in senders' policy.  It's only useful if it
helps their own systems work better.

R's,
John

---

From: Jim Fenton <[email-masked]>
Date: Thu, 09 Nov 2006 19:15:55 -0800

[Back on the original topic]

Good input, Pat; thanks.  Comments below:

> unsigned/invalid signature email.
We have been very careful to be declarative rather than imperative in 
SSP for the following reason.

Very early on (during the WG chartering process), we got input from 
several people that laws in the EU prohibit an email service provider 
from honoring instructions from a purported sender to drop messages from 
others.  From what I have been told, the [snail-mail] postal model is 
followed closely:  the delivery agent has an obligation to deliver the 
message, even if it may be forged.  I'm currently trying to get more 
specifics on whether this is spelled out somewhere, or is just an 
extrapolation of the delivery of "post".  While this could probably be 
resolved by having those subject to these regulations just not implement 
message rejection, we didn't want the perception to be that DKIM 
violates laws in some jurisdictions.

It may very well be that this is OK if the recipient opts-in for this 
service, or something like that.

In any case, the notion of "Suspicious" was chosen to not be too 
specific, but cover the case where the verifier (for example) rejects 
messages which are suspicious.

I'll report back to the list when I get more specifics on the legal 
aspects (or whether there was a miscommunication somewhere).
> policy and they universally said yes. 
My objections to an "I send no email" policy in SSP, all flexible, are:
1. SPF/SIDF already says that.  I'd be interested in why they want to 
say this in SSP as well, which someone else asked but I missed the 
answer if there was one.  Having the information in more than one place 
means you need to define what happens in the event of conflict.
2. "I send no email" is not really a DKIM policy, it's a mail policy.  
I'm concerned about there being a slippery slope of policies if we 
venture outside DKIM.  But we can probably manage that, so this is more 
of a principle than something that doesn't work.
3. I'd rather preserve the characteristic that the verifier doesn't have 
to check SSP if there's a valid signature from the author (From 
address).  If we can define it that a valid signature overrides the "I 
send no email" policy, this point is solved.

> good compromise solution.)
Presumably this action would be independent of whether the verifier 
rejects, discards, annotates, etc. the message when there is a failure.  
I guess the 'postmaster' address must too overworked for this task.

There are a couple of ways to do this reporting:
1. Create a new well-known address that is used for reporting DKIM failures.
2. Include a reporting address in the SSP record.

In the case of #1 is that there would still need to be a flag somewhere 
asking the verifier to send the problem report.  In either case the 
verifier should expect the address to be the recipient of a lot of 
abuse.  #2 has the advantage that it could be turned on for short 
periods, or addresses could be rotated frequently enough that 
(hopefully) the unwanted mail could be managed.

I'm not crazy about tying this to SPF records.  I expect that some of 
the problems that are reported via this mechanism will have to do with 
unexpected forwarding through agents that modify the message in some 
way, and in those cases SPF is also likely to fail.

-Jim

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 10 Nov 2006 14:47:15 -0000

> service, or something like that.

I would have thought so.

And I would have thought it extrememly bad practice for any ISP to be  
dropping any mail unless there is a specific opt-in, whether it would be  
unlawful to do otherwise, or not.

For example, my own provider offers a service to run Spamassassin, which I  
have gladly accepted. But I had to take positive action to turn it on  
(there is a form on their website for doing that alongside lots of other  
configuration options, including the Spamassassin level at which you want  
the cutoff, and whether you want it dropped in the bit bucket of just  
marked.

I am in the EU BTW, and have not heard of any problem with this sort of  
filtering, which is quite widespread AIUI. Indeed our Post Office has an  
obligation to deliver whatever is sent (even Craig Shergold could not  
avoid that), but certainly in the UK ISPs are not Common Carriers, just as  
they are not in N. America.

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 10 Nov 2006 16:54:06 +0100

Jim Fenton wrote:

> we got input from several people that laws in the EU prohibit an email
> service provider from honoring instructions from a purported sender to
> drop messages from others.

IANAL etc., but please note "drop" here...

> this could probably be resolved by having those subject to these
> regulations just not implement message rejection

...and "rejection" there.  Potentially DROP can violate laws or RFC 2821.
OTOH "reject" can't be illegal anywhere, nobody's forced to accept spam,
and if it's a false positive the sender gets a non-delivery notification.

Of course receivers should check that a "purported sender" really is the
originator before accepting "suspicious" mails, but that's another issue.

> messages which are suspicious.

My POV is exactly the opposite of your concept, "of course" (?) "reject
is okay", and receivers could get a similar effect with "drop", but they
better discuss this with their legal department.  While they're at it
they should also discuss any legal issues of sending bounces to innocent
bystanders, especially complete malware - only relevant for receivers
implementing a "reject" after their "you lose" point (= their border MX).

> Having the information in more than one place means you need to define
> what happens in the event of conflict.

Receivers pick what they like better, if in doubt "reject" is always the
best action at their border, after that it turns into "better deliver or
be damned".  It's not the problem of the receiver if a sender screws up.

And some receivers supporting DKIM won't bother to check SSP or SPF or
what else, like some receivers supporting SPF won't bother to look into
SSP, unless they also do DKIM.  Receivers are free to do whatever they
like - as long as they're extremely careful with DROP and BOUNCE... :-)

> "I send no email" is not really a DKIM policy, it's a mail policy.
> venture outside DKIM.  But we can probably manage that, so this is
> more of a principle than something that doesn't work.

+1

> way, and in those cases SPF is also likely to fail.

Reporting 551-errors (incl. its SPF-emulation after forwarding) works
as designed in RFC 821.  It doesn't work this way for random reports
and auto-replies (SenderID, DKIM, C/R, etc.), unless it's based on a
PASS or minimally on some kind of "not-FAIL".  If the Return-Path is
out the next stops are postmaster@, abuse@, rfc-ignorant.org, ...

Frank

---

From: John Levine <[email-masked]>
Date: 10 Nov 2006 16:27:59 -0000

>say this in SSP as well, ...

Presumably that's so that DKIM doesn't depend on SPF.

>2. "I send no email" is not really a DKIM policy, it's a mail policy.

This is really the most important point, since this bit of policy is
just as useful to people who don't use DKIM and never will.  There are
other proposals such as MX dot that let domain owners publish this bit
without the extra cruft of SSP or SPF.

>send no email" policy, this point is solved.

I sure hope so.  The work to create a DKIM key pair and publish them
in one's DNS is greater than to set a flag in an SSP record, so in
case of collision, the DKIM record is at least as credible.

>> Requirement #3. Feedback of invalid signature/unsigned mail

Senders need to keep in mind that they're asking recipients to do them
a potentially large favor here, so if there's a mechanism it needs to
be really simple and easy for recipients to do.  A flag encouraging
reports to a fixed well known address seems the simplest option.

>> (Without going too far down the solution avenue, senders felt one
>> possible solution to receiving an excessive number of
>> invalid/unsigned feedback emails during a large-scale spoofing
>> attack was to state that they only wanted feedback for emails which
>> originated from their IP space as defined by their SPF record.

Speaking as a receiver, that's a bigger favor than I am offering for
free.  If senders want the feedback, it's their problem to weed out
the noise, not mine.  If receivers out of the goodness of their hearts
want to do some prefiltering, they can figure out how to do so without
having it written into a standard.

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Fri, 10 Nov 2006 08:27:17 -0800

Thanks Pat, this is useful feedback. Inline:

>unsigned/invalid signature email.

The current taxonomy only has bullet 1 and something inbetween bullet 2 
and 3.
There's quite a bit of contention about flat out stating what a receiver 
should do,
which is quite reasonable: we really can't predict why receiver's do 
what they
do (should a honey pot, for example, drop them too?). In the 
requirements draft,
SSP was presented as being an information service first and foremost. In 
that vein
it seems fine for a service to report some bogosity scale, but stop 
short of declaring
the actual message disposition. In reality, if the protocol is 
successful I can't imagine
that the receivers won't do exactly what you hope. But by not specifying 
drop it
does save us from a really unpleasant rathole which is ultimately futile 
for us to
specify anyway: a receiver will dispose of the message as they see fit 
regardless
of what we say.

>good compromise solution.)
Here's a question: is this a severable problem from SSP itself? My 
limited experience
with Murray's auto-magic error reporting in his DKIM milter is that this 
a very
complicated problem and that we have not considered it in any depth. 
What are the
security considerations (ddos?)? What is the reporting mechanism? What 
exactly
do they need to glean from the report? Should these be summaried? What 
about the
information leakage implications? Etc, etc. I'd be *extremely* nervous 
to just throw
this in without much thought as the likelihood of unintended 
consequences  seems really high.

>as they see fit, but providing them with more granular information is

Yeah, but I'm afraid that actually offering disposition advise is going 
to lead us
down that problematic rathole. Frankly, I'm rather worried about just 
the opposite
of what you're customers have been saying: that receivers will 
*overreact* to a
failed signature, especially in the 1st scenario.

       Mike

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 10 Nov 2006 18:28:59 +0100

John Levine wrote:

> There are other proposals such as MX dot

All long dead at the moment:

Expired 2005-10: draft-stumpf-dns-mtamark-04.txt
Expired 2005-10: draft-delany-nullmx-00.txt
Expired 2004-10: draft-lorenzen-marid-mxout-00.txt

There used to be an older RHSBL for senders never
sending mail, but I forgot its name.  The existing
RFCs 4408 and 4406 cover HELO, MAIL FROM, and PRA.
For a receiver interested in those identities that
should be good enough.

For a DKIM SSP the 2822-From would be a different
identity.  I've no clue why a receiver would wish
to check some 2822-From policy if there's no valid
DKIM signature, or what a policy "I never send any
mail" means if the mail has a valid DKIM signature.

And I don't know who that "I" is, it's perfectly
okay if an author is listed in the 2822-From, but
never sends mail - for that case RFC 822 offers a
Sender header field.  There's even a Resent-Sender
if a given Resent-From didn't resend the mail.

Frank

---

From: Jim Fenton <[email-masked]>
Date: Sun, 12 Nov 2006 08:02:53 -0800

Charles Lindsey wrote:
>> from honoring instructions from a purported sender to drop messages 
>> from others.  From what I have been told, the [snail-mail] postal 
>> model is followed closely:  the delivery agent has an obligation to 
>> deliver the message, even if it may be forged.  I'm currently trying 
>> to get more specifics on whether this is spelled out somewhere, or is 
>> just an extrapolation of the delivery of "post".  While this could 
>> probably be resolved by having those subject to these regulations 
>> just not implement message rejection, we didn't want the perception 
>> to be that DKIM violates laws in some jurisdictions.
>>
> dropping any mail unless there is a specific opt-in, whether it would 
> be unlawful to do otherwise, or not.
If you go to the message that Pat Peterson wrote that started this 
thread, that is exactly what some domains would like to do.  They 
consider SSP to be helpful to counter phishing [Please, let's not 
re-open that question; it has been discussed to death] even if it is 
ineffective with look-alike domains and such.  The requirement for the 
recipient to opt-in to have unsigned messages from their domains removed 
diminishes that perceived benefit greatly.

-Jim

---

From: Dave Crocker <[email-masked]>
Date: Sun, 12 Nov 2006 12:03:07 -0800

> diminishes that perceived benefit greatly.

(I mean to post a thank-you to Pat for his note.  That kind of market research 
is always helpful.)

Oddly, Pat's research adds an interesting challenge for the wg.  End users state 
end-state goals.

They are not attempting to specify a path to achieve it.  That's our job.

Standards groups often try to specify all of a complex solution, because they 
are trying to respond exactly to the (imagined, perceived, or researched) 
end-user's description of what they want.  It is what usually kills really 
interesting efforts, because the task is too complex, in its entirety, to do all 
at once.

So, I claim, our challenge is to take the end-user desire and figure out an 
initial deliverable that is as small as possible, while still providing real 
utility to the end-user, even if that utility is not a complete "solution" to 
whatever they have asked for.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "John Glube" <[email-masked]>
Date: Wed, 15 Nov 2006 14:33:54 -0500

<snip>

I apologize for the late post.

(Side note: This email is coming from my gmail address.
However, I am writing this email in my role as compliance /
abuse manager for an e-messaging application service
provider (ESP) known as BigHip.com.)

BigHip has seen its domain both phished and forged.

We perceive that being able to publish an SSP is important.
Hence this post.

Why? BigHip publishes an RFC 2822 sender header to identify
that all email is being sent from its network.

(Side note: This is consistent with best practices for
e-marketers as found in the Canadian Spam Task Force
Report.)

In turn, BigHip signs its mail (presently using DK)
verifying the sender header.

(Side note: we use the domain bighip.com in our RFC 2821
and RFC 2822 headers, except for the RFC 2822 From header.
The client provides the domain for use in the RFC 2822 from
header.)

This approach allows for compliance with best practice,
while making it easy to implement various authentication
technologies, including DKIM, but ....

Only if receivers allow for verification of the sender
header.

As the responsible sender, (even though we are an ESP, the
mail is coming from our network), we can not tell receivers
what to do. It is their network.

But, through the use of an SSP, we can make certain
statements about our policies.

In turn, receivers can, if they wish, take these
statements into account when making decisions about how to
treat mail coming from our network.

Possible SSP statement: -

We sign all mail, verifying the RFC 2822 sender header. No
signature or invalid signature, providing receiver checks
and verifies RFC 2822 sender header and not just RFC 2822
from header, reject with appropriate non delivery receipt
sent at SMTP time. Bad signature, defer with appropriate
non deliver receipt sent at SMTP time, allow for re-send
and delivery.

Accordingly, I am asking that:

* The working group pushes forward with its work on SSP.

* When writing the SSP, the working group takes into
account that there is a group of senders (who mail on
behalf of others) that follow recommended practices by
publishing a sender header, who would like to sign the
sender header, have this signature verified and want to
protect the domain in the sender header from phishing and
forgery attacks.

Thanks,

John

John Glube
Bighip - Compliance / Abuse officer
http://www.bighip.com
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Steve Atkins <[email-masked]>
Date: Wed, 15 Nov 2006 11:43:11 -0800

> protect the domain in the sender header from phishing and

Is the content of the Sender header commonly used
by the end-user, or even visible to them?

If not, how is it directly relevant to "phishing and forgery
attacks"?

(I'm not arguing that having a Sender header that points
at the sender is anything other than a good thing, or even
that having some Sender-specific foo in some hypothetical
SSP spec would be a bad thing, just the line of reasoning.
I think you're skipping over some details that are important
to bring up explicitly.).

Cheers,
   Steve

---

From: Arvel Hathcock <[email-masked]>
Date: Wed, 15 Nov 2006 16:37:14 -0600

> by the end-user, or even visible to them?

I know that Microsoft Outlook (an important and significantly deployed 
mail client) displays the Sender header if one is present.

-- 
Arvel

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 16 Nov 2006 09:04:21 -0500

> mail client) displays the Sender header if one is present.

Most others don't be default.  As an example, for Thunderbird there is an 
extension you can add that supports this.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 16 Nov 2006 09:14:41 -0500

> protect the domain in the sender header from phishing and

This may be a use case that requires the designated signing domain feature, if 
I understand it correctly.

If the message is:

From: [email-masked]
Sender: [email-masked]

Then without an ability to designate a signing domain, the message would have 
to be signed twice (once by each domain) to protect both headers.

With the ability to publish a list, then the message could be signed once with 
one domain (the customer domain I would imagine) publishing policy saying 
that bighip.com was authorized to sign mail for them.

I'm not sure which approach would be better.  Two signature places a burden on 
every receiver whether they care about SSP or not.

Scott K