Subject: [ietf-dkim] DKIM Japan has been set up

From: Tsuneki Ohnishi <[email-masked]>
Date: Sat, 20 Nov 2010 11:49:36 +0900

Hi to all,

I am Tsuneki Ohnishi and I would like to let you know
that DKIM Japan(dkim.jp) has just been set up as of
Nov 15, 2010. 

It's a non-profit organization and its main purpose is
to share information and to clear the decks for the 
nationwide implementation of DKIM.

Our board members consist of top major companies like
Yahoo! Japan, Sendmail, Rakuten Inc., Nifty Corp,
PIPED BITS Co.Ltd, and infomani@ Inc. Other members
sum up to about 30 companies now, consisting of major
ISPs, ebiz companies and security vendors. We also 
have the Ministry of Public Management, Home Affairs, 
Posts and Telecommunications as an observer.

I am the company owner of infomani@ Inc and speaking
on behalf of dkim.jp. What I would like to do here 
is to share information and possibly contribute to the
community by giving feedback from what we're trying to
do in Japan.

I may ask some dumb questions since I am new here,
but I hope I'm welcome. :-)

Tsuneki Ohnishi
infomani@ Inc.

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

---

From: "Mark Delany" <[email-masked]>
Date: 20 Nov 2010 06:37:56 -0800

> that DKIM Japan(dkim.jp) has just been set up as of

Welcome, Tsuneki, glad to have you join. It's great news to hear of
such commitment.

Who knows? Maybe .jp will be the first ccTLD to get comprehensive DKIM
coverage. Wouldn't that be something!

Mark.

---

From: Byung-Hee HWANG <[email-masked]>
Date: Sun, 21 Nov 2010 15:40:34 +0900

Tsuneki,

> but I hope I'm welcome. :-)

Welcome to DKIM world! Sadly, there is no man interested in DKIM in
Korea. Go for it DKIM without stop, thanks!

Sincerely,
  
-- 
소여물 황병희(黃炳熙) | .. 출항 15분전..

"It's Johnny, he came to the wedding, what did I tell you?"
"It's really your godson."
		-- Vito Corleone and Tom Hagen, "Chapter 1", page 33
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Tsuneki Ohnishi <[email-masked]>
Date: Mon, 22 Nov 2010 11:43:00 +0900

Thanks, Bill, Mark and Byung-Hee for the warm welcome.

Yes, we gotta start something somewhere and glad to 
let you know that we are staring something here.
If possible, let's work together for the spread out
in eastern asia, Byung-Hee. 

Well, let me give you the first feedback of what's
been discussed at the point of implementation here, 
and I would like to ask your opinions.

Here is our stuation. Members of dkim.jp so far circulate
somewhat like 30% of domestic emails and a lot more forged
emails coming from overseas, especially forged @yahoo.co.jp
and @rakuten.co.jp. So with the initiative of those two 
companies and others, we got together to get rid of those
forged emails.

Senders in dkim.jp are committed to attach DKIM signature
withing 6 months, and possibly ready to write their ADSP
"discardable". Since we have major ISPs on our member list
and they are very willing to discard unveryfied emails,
no surprise about it :-), we are trying to inch up to the
level where all domestic emails are signed and verified.

But there is a small problem. It is rather polical.
We have a telecommunication law that allows ISPs to discard
forged email, but our Ministry so far does not acknowledge
that failure of DKIM verification immediately equals to 
forgery, because there could be other reasons to fail.

We can fight about it taking time to get through to dull
Japanese bureaucracy, but I think there is a faster way.
It is to let senders to have an option to declare that
if there is no DKIM signature at all, verifiers can discard
those messages. Then we can shut their mouths insisting
there could be other reasons.

So, my point is that what do you think of the idea to have
an new entry in ADSP "discard-if-no-sig", which allows
senders to declare messages without DKIM signature should
be discarded?

If that's possible, it makes our job a lot easier and faster.

Thanks,

Tsuneki Ohnishi

---

From: Hector Santos <[email-masked]>
Date: Mon, 22 Nov 2010 00:49:15 -0500

> If that's possible, it makes our job a lot easier and faster.

Hi.

You are basically asking to make a distinct difference between:

   1) a real no signature message versus
   2) a message who's signature is broken (invalid).

The DKIM specification says that a broken signature is the same as no 
signature message.

It is important to know the difference because if you are concern 
about a Real No-Sig versus a Broken one where a Real No-SIG is 
discarded but a Broken one is not, then whats to stop the Bad Guy from 
adding a broken signature by design and for the sole purpose of making 
sure the message is now indeterminate and you don't filter it?

The problem with DKIM is the is the "stuff in the middle" - A real 
no-sig message can be made to work, as well as when there is a valid 
signature.

It the faults of the system that is challenging - what do you do with 
failures and what makes it even more difficult is the specifications 
has evolved to one where where any system, middle-ware or hop, can 
break or remove an author domain signature without restrictions.  This 
was done to appease the LIST managers, 3rd party signer and the 
reputation market.

IMO, I think DISCARD should cover what you want, but you have to view 
it as a strong policy with no exceptions, i.e., a broken signature is 
just as bad as no-signature and more importantly, no interference or 
3rd party signers can override the message author domain security 
expectations.

If you allow for broken signatures to be "acceptable" partially or 
otherwise in an ADSP setup, then it just confuses the intent and it 
potentially feeds bad guys to give you broken signatures because that 
is "OK" by you.

Right now, there is no incentive for bad guys to adapt or change. They 
can remain in legacy operations (no signature) because there is no 
wide adoption or foundation for DKIM policies or the handling of 
policy faults.

Having a "MUST SIGN" policy widely adopted (and supported) would begin 
to make a change in legacy operations.  They will most likely avoid 
your POLICY protected domain.  But if you allow for broken ones, then 
they can adapt by adding a spoofed but broken signature.

-- 
Hector Santos, CTO
http://www.santronics.com

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 22 Nov 2010 10:16:50 +0100

Hi Tsuneki,
first of all, since I write, let me make my welcome-on-list explicit!

> level where all domestic emails are signed and verified.

I hope you'll get replies more qualified than mine...
FWIW, I suggest you do not use ADSP that way.

> But there is a small problem. It is rather political.

IMHO, your Ministry is correct.

> there could be other reasons.

As an alternative, it is the recipients who may eventually decide they
are not interested in receiving unsigned contributions to their
inboxes, unless they have other means to identify those messages.
IMHO, such decision should be made by each recipient individually.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Tsuneki Ohnishi <[email-masked]>
Date: Tue, 23 Nov 2010 02:06:17 +0900

Thanks for your comment, Hector and Alessandoro.

I understand your point. 
First, Alessandoro, let me reply to your comment.

Yes, very true, it is recipients' choice to discard messages.
But in fact, that choice is lost for now because our Ministry 
does not allow that. My idea was to build another level of
ground where the author, recipients and the Ministry can agee on, 
"if-no-sig then discardable".

And I see your point, Hector. If we draw a line between Sig and No-sig,
that would allow broken signature to be accepted. But as you poited out,
bad guys still remain in legacy operation, so the line between Sig and
No-sig works for the time being. I know that it is not the best way to
do it, but it could be a practical step to the wider adoption. Because
if that option gets valid, I am sure more authors would choose it at
least here in Japan. I don't think that undermines the effectivenes of
DKIM, because one can always rewrite his ADSP 'discaradable' if the bad
guys start spoofing with forged signatures.

Well, it's just a newbie's idea, so may be totally unacceptable.
But please understand that we're heavily committed. 
Gotta find a way through.

Tsuneki Ohnishi
infomani@ Inc.

On 2010/11/22, at 14:49, Hector Santos wrote:

> The DKIM specification says that a broken signature is the same as no signature message.
> 
> It is important to know the difference because if you are concern about a Real No-Sig versus a Broken one where a Real No-SIG is discarded but a Broken one is not, then whats to stop the Bad Guy from adding a broken signature by design and for the sole purpose of making sure the message is now indeterminate and you don't filter it?
> 
> The problem with DKIM is the is the "stuff in the middle" - A real no-sig message can be made to work, as well as when there is a valid signature.
> 
> It the faults of the system that is challenging - what do you do with failures and what makes it even more difficult is the specifications has evolved to one where where any system, middle-ware or hop, can break or remove an author domain signature without restrictions.  This was done to appease the LIST managers, 3rd party signer and the reputation market.
> 
> IMO, I think DISCARD should cover what you want, but you have to view it as a strong policy with no exceptions, i.e., a broken signature is just as bad as no-signature and more importantly, no interference or 3rd party signers can override the message author domain security expectations.
> 
> If you allow for broken signatures to be "acceptable" partially or otherwise in an ADSP setup, then it just confuses the intent and it potentially feeds bad guys to give you broken signatures because that is "OK" by you.
> 
> Right now, there is no incentive for bad guys to adapt or change. They can remain in legacy operations (no signature) because there is no wide adoption or foundation for DKIM policies or the handling of policy faults.
> 
> Having a "MUST SIGN" policy widely adopted (and supported) would begin to make a change in legacy operations.  They will most likely avoid your POLICY protected domain.  But if you allow for broken ones, then they can adapt by adding a spoofed but broken signature.
> 
> -- 
> Hector Santos, CTO

--------------------------_____________________________
 株式会社インフォマニア ≫ http://www.infomania.co.jp/
    代表取締役　大西恒樹 ≫ TEL 045-914-5304 FAX 5404
   　迷惑メールフィルター ≫ http://www.answre.jp/
       Pizzeria マルターノ ≫ http://www.martano.jp/
        twitter アカウント　≫ mjwords
　　　 ---------------------------------------------

---

From: Steve Atkins <[email-masked]>
Date: Mon, 22 Nov 2010 09:25:26 -0800

> forgery, because there could be other reasons to fail.

That's not political, that's technical. Mail that is validly
DKIM signed when it's sent may not be DKIM signed
when it is received.

If you discard mail that isn't DKIM signed just because
you expected it to be DKIM signed, you'll end up discarding
quite a lot of email. And the errors aren't likely to be
terribly random, rather they'll be related to particular
mail paths, so some people will see a lot of mail wrongly
discarded.

ADSP is better than SPF, but it's still not something anyone
should consider deploying widely as a primary means
of deciding to discard inbound email.

> senders to declare messages without DKIM signature should

If you're just trying to stop email such as virus blowback
then something simple like that will work OK, some of the
time. It's more complex, and less effective, than other approaches
so it's not a really good idea.

But if you're trying to stop mail that's being sent by a bad
actor... give up on this approach, as it's trivial to add a "fake" 
DKIM header that will not authenticate.

Also, it may discard quite a bit
of legitimate email, if any of your users subscribe to mailing
lists (some mailing list managers are likely to strip out
DKIM headers in the cases where they know they'll invalidate
them).

Cheers,
  Steve

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 22 Nov 2010 10:37:13 -0800

> forgery, because there could be other reasons to fail.

There are technical and operational reasons that can cause legitimate mail that 
was originally signed with a legitimate DKIM signature, to fail to verify.

The fact that a signer signs all their mail does not mean that all their mail 
will arrive with a valid signature.

Simply publishing an ADSP record does not change this fact.  ADSP can perhaps be 
used productively for specific signers and verifiers, but it does not work for 
all legitimate scenarios.

d/
-- 

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

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 22 Nov 2010 17:23:47 -0500

On Monday, November 22, 2010 01:37:13 pm Dave CROCKER wrote:
> There are technical and operational reasons that can cause legitimate mail
> that was originally signed with a legitimate DKIM signature, to fail to
> verify.
> 
> The fact that a signer signs all their mail does not mean that all their
> mail will arrive with a valid signature.
> 
> Simply publishing an ADSP record does not change this fact.  ADSP can
> perhaps be used productively for specific signers and verifiers, but it
> does not work for all legitimate scenarios.
> 
What does work for all legitimate scenarios?

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Mon, 22 Nov 2010 14:50:23 -0800

On 11/22/10 9:25 AM, Steve Atkins wrote:
> ...
Agreed. DKIM does not offer a comprehensive method to qualify the source 
of a message.  Extensions, such as the TPA-Label scheme, could extend 
signing policy to include other authentication and authorization methods 
and retain delivery integrity.  ADSP using just DKIM is likely to cause 
a significant loss of legitimate email, especially when DISCARDABLE is 
asserted.

-Doug

---

From: "John R. Levine" <[email-masked]>
Date: 22 Nov 2010 23:48:57 -0500

We really need a FAQ for this group.

> What does work for all legitimate scenarios?

Short answer: nothing.

Slightly longer answer: the problem with ADSP is that, based on my limited 
but I think credible statistics, most people who publish ADSP don't know 
what it means, so blindly following ADSP advice from random domains is 
more likely to discard real mail than phishes.

There certainly are some domains that sign all their mail, don't mix 
individual with transactional mail, and are phish targets.  Paypal.com is 
the standard example.  Competently maintained lists of those domains would 
provide useful advice for discarding likely phishes.  Back in June I wrote 
draft-levine-dbr-00, which describes Denounce-By-Reference, a simple way 
to publish such lists in the DNS.

Anyone want to move it along?

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 23 Nov 2010 11:14:53 +0000

> of deciding to discard inbound email.

Actually, they're complementary. In places where DKIM fails (mailing lists 
rewriting messages), SPF can succeed. And in places where SPF fails 
(message forwarding), DKIM can succeed.

Messages can have a reasonable level of trust if they achieve either an SPF 
pass for a trusted domain, OR an DKIM verification for a trusted signer. Of 
course, you still need to check for malware and be wary of messages from 
compromised accounts.

Deployment of SPF and DKIM are both low enough that you can't either reject 
or discard messages simply because they don't pass or verify. But, we 
already give a small negative spam score for SPF softfail and neutral 
results, and haven't had any complaints. For DKIM it's harder, but for 
certain author domains (including those that publish ADSP discardable, it 
might be worth considering downgrading messages - especially when combined 
with SPF fail/neutral/softfail).

-- 
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 23 Nov 2010 06:26:57 -0500

>> What does work for all legitimate scenarios?
Right. It also doesn't wax my car, which is equally relevant.

ADSP certainly isn't ideal, but (unlike the rest of your message) saying something "does not work for all legitimate scenarios" is not a useful contribution to the discussion.

Scott K

---

From: Tony Hansen <[email-masked]>
Date: Tue, 23 Nov 2010 08:50:46 -0500

Welcome Tsuneki.

Instead of using failed DKIM signatures as a way to blacklist messages
and potentially discard them, I suggest you concentrate on ways to use
verified DKIM signatures along with reputation mechanisms in order to
whitelist messages. You can highlight such messages, or give them
preferential treatment, or use other mechanisms to segregate them from
other messages. (In the last category, I include all messages that have
no signature, an invalid signature, as well as verified signatures from
an unknown or less-than-good reputation.)

Tony Hansen
[email-masked]

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 23 Nov 2010 15:49:28 +0000

--On 23 November 2010 02:06:17 +0900 Tsuneki Ohnishi 
<[email-masked]> wrote:

> 5068

My view is that this is a long term game. You can help by encouraging 
uptake of DKIM, and deploying domain based reputation engines. If your 
major public ISPs, corporate, and government sites make use of these 
things, then deliverability will be improved for legitimate mailers who 
deploy DKIM.

You also need to encourage deployment of RFC5068, in order that sent emails 
are more likely to be properly routed through the relevant DKIM signing 
engines.  <http://www.apps.ietf.org/rfc/rfc5068.html>

I'd also suggest deploying SPF as a complimentary technology. Most email 
paths preserve either DKIM or SPF, even when one or other is not preserved. 
They both permit the use of domain based reputation engines, although the 
domains protected will not always be the same.

Finally, promote the use of MTAs that can verify DKIM during the SMTP 
session. This way, messages can be rejected rather than discarded, if 
there's a problem. Rejection of messages at SMTP time permits the sender to 
be aware of problems with false positives.

---

From: "John R. Levine" <[email-masked]>
Date: 23 Nov 2010 12:18:44 -0500

> rewriting messages), SPF can succeed.

Haven't we been over this a hundred times already? It's ADSP, not DKIM, 
that fails on mailing list mail.

DKIM works just dandy, when lists sign their mail like this one does.

Regards,

---

From: Ian Eiloart <[email-masked]>
Date: Wed, 24 Nov 2010 11:21:06 +0000

--On 23 November 2010 12:18:44 -0500 "John R. Levine" <[email-masked]> 
wrote:

>> Actually, they're complementary. In places where DKIM fails (mailing
>> lists rewriting messages), SPF can succeed.
>

A good point. And SPF works just dandy if the intermediary uses SRS. I'll 
rephrase:

Unless the intermediary co-operates by re-signing, mailing lists can break 
DKIM signatures. Since mailing lists generally use their own rfc5321 return 
paths, SPF failures should not result. Of course, a broken DKIM signature 
is equivalent to none at all. You should not reject or discard mail on this 
basis, but you do lose the ability to assign signer domain based reputation 
to the message.

Unless the intermediary co-operates with SRS, or similar, *forwarding* can 
result in SPF failure. Since forwarders generally don't change the message 
content, DKIM signatures should remain intact.

---

From: Wietse Venema <[email-masked]>
Date: Wed, 24 Nov 2010 09:53:41 -0500 (EST)

> content, DKIM signatures should remain intact.

Please do not confuse mailing lists with email forwarding. The two
are different things. It is not helpful to take an argument from
one context and use that to "prove" a point in the other context.

	Wietse

---

From: "John R. Levine" <[email-masked]>
Date: 24 Nov 2010 10:42:01 -0500

This really does need to be a FAQ.

> DKIM signatures.

Quite true.  But broken signatures are only a problem in a mutant version 
of DKIM unlike the one specified in RFC 4871, so it's not a problem.

> but you do lose the ability to assign signer domain based reputation 
> to the message.

Unless, of course, the list signs like this one does.  I don't see any 
reason to think it's less likely that lists sign than that list 
contributors sign.  Do you?  Concrete numbers would help here.

Anecdotes: all the Yahoogroups lists sign.  All of my lists sign.

Regards,

---

From: Ian Eiloart <[email-masked]>
Date: Wed, 24 Nov 2010 15:46:38 +0000

--On 24 November 2010 09:53:41 -0500 Wietse Venema <[email-masked]> 
wrote:

> Ian Eiloart:
>> Unless the intermediary co-operates by re-signing, mailing lists can
>> break  DKIM signatures. Since mailing lists generally use their own
>> rfc5321 return  paths, SPF failures should not result. Of course, a
>> broken DKIM signature  is equivalent to none at all. You should not
>> reject or discard mail on this  basis, but you do lose the ability to
>> assign signer domain based reputation  to the message.
>>
>> Unless the intermediary co-operates with SRS, or similar, *forwarding*
>> can  result in SPF failure. Since forwarders generally don't change the
>> message  content, DKIM signatures should remain intact.
>

I'm not confusing the two. DKIM and SPF both permit the use of domain based 
reputation databases. Unfortunately, both have problems with various paths 
that emails may take. Fortunately, the problematic paths are different - 
mailing lists are problematic for one, and forwarding is problematic for 
the other.

My point that DKIM and SPF can complement one another therefore relies on 
an understanding that mailing lists are not forwarders.

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 24 Nov 2010 17:02:36 +0100

On 24/Nov/10 16:46, Ian Eiloart wrote:
> DKIM and SPF both permit the use of domain based reputation
> databases. Unfortunately, both have problems with various paths 
> that emails may take. Fortunately, the problematic paths are
> different - mailing lists are problematic for one, and forwarding
> is problematic for the other.
>

+1.  For different reasons, both ADSP and SPF seem to need a revision.
 Is there an opportunity to be taken here?
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 24 Nov 2010 16:10:24 +0000

Let's not do this on this list.

---

From: Ian Eiloart <[email-masked]>
Date: Wed, 24 Nov 2010 16:09:10 +0000

--On 24 November 2010 10:42:01 -0500 "John R. Levine" <[email-masked]> 
wrote:

>> break  DKIM signatures.

That depends on whether a loss of an opportunity is a problem. When you 
break a signature, the recipient loses the opportunity to apply reputation 
information to the message, or to use the message to update their 
reputation database. The sender loses the opportunity to benefit from any 
reputation that they've built.

If breaking one signature isn't a problem *at all*, then perhaps breaking 
all signatures isn't a problem. By extension, loss of the DKIM project 
wouldn't be a problem.

Of course, I don't believe that. I think DKIM has value, and the better the 
uptake the higher the value. Broken signatures are equivalent to lower 
uptake.

> Unless, of course, the list signs like this one does.

Yes, I think that "Unless, of course, the list signs" has the same meaning 
as "Unless the intermediary co-operates by re-signing". So I think we're 
agreed there.

> I don't see any reason to think it's less likely that lists sign than 
that list
> contributors sign.  Do you?  Concrete numbers would help here.

I don't see any reason to think that. However, my inbound mail stream 
(after filtering) mostly comes from domains that have SPF (about 90% 
passing), but a bit under half carries a DKIM signature (about 90% intact). 
So, for me, DKIM is a fallback to look at when an SPF test doesn't pass.

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 24 Nov 2010 08:58:32 -0800

On 11/23/2010 5:50 AM, Tony Hansen wrote:
> whitelist messages.

+10

d/
-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 24 Nov 2010 09:01:27 -0800

> (message forwarding), DKIM can succeed.

This assertion of facts is almost certainly incorrect.

Please specify the details of the scenarios in which you claim these assertions 
are correct.

d/
-- 

   Dave Crocker

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 24 Nov 2010 16:11:07 +0000

>  Is there an opportunity to be taken here?

Not in this WG with this charter.

Let's get done with out work items.

S.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 24 Nov 2010 10:57:58 -0800

On 11/24/10 9:01 AM, Dave CROCKER wrote:
> > Actually, they're complementary. In places where DKIM fails
> > (mailing lists rewriting messages), SPF can succeed. And in places
> > where SPF fails (message forwarding), DKIM can succeed.
>
>  Please specify the details of the scenarios in which you claim these
>  assertions are correct.

+1

---

From: "Mark Delany" <[email-masked]>
Date: 24 Nov 2010 11:38:52 -0800

> >  Please specify the details of the scenarios in which you claim these

-10 Please don't. It's out of scope for this group.

Mark.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 24 Nov 2010 13:44:02 -0800

> -10 Please don't. It's out of scope for this group.
+100 (see your magnitude and raise you one) :^)

Perhaps the best place to continue the discussion is on the asrg list. 
It would be nice if there were a 5321-ietf mailing list.

-Doug

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Wed, 24 Nov 2010 22:57:42 +0100

> It would be nice if there were a 5321-ietf mailing list.

There is one: [email-masked]
Or are you looking for a 5321-specific list?

/rolf

---

From: Ian Eiloart <[email-masked]>
Date: Thu, 25 Nov 2010 12:28:33 +0000

--On 24 November 2010 09:01:27 -0800 Dave CROCKER <[email-masked]> wrote:

>> lists rewriting messages), SPF can succeed. And in places where SPF fails

OK: A sender publishes SPF records, with -all, and DKIM signs outgoing 
messages.

A recipient checks both SPF and DKIM.

If the message goes through a forwarder, who doesn't alter the message or 
the return-path, then the recipient will see an SPF fail, but the DKIM 
signature will be good. The sender can ensure that there's something that 
the recipient can use to apply domain reputation. I think the second 
assertion above is quite simply demonstrated.

With mailing lists, it's a bit more complicated - but there's good reason 
for using both when there are no intermediaries at all - see below. Neither 
DKIM nor SPF are end-to-end with mailing lists, since the list will change 
the return-path (at least you don't get SPF false negatives), and DKIM 
signatures are likely to be broken if they protect the full body. Of 
course, the list operator might usefully publish SPF records, sign their 
outbound messages, or both.

But, with mailing lists, the sender can only do their best to have the 
message accepted by the list. Beyond that, there's little influence (other 
than that ADSP can harm onward delivery).

However, list managers will want to screen incoming messages. Mailman will 
accept messages where the return-path OR From: header address, OR Sender: 
header address is a member's email address. So, all these addresses need 
protection. DKIM can't protect the return path address, but SPF can. If a 
message doesn't have a member's address in the headers, has the address in 
the return-path, but SPF is published, but results in a "fail", then it may 
be wise to reject the message. Here, DKIM has failed in the sense that it 
has failed (by design, so perhaps "fail" is too strong a word) to say 
anything about the acceptability of the message.

Without intermediaries
----------------------

There are some simpler use cases, where there is no intermediary. If the 
sender and recipient are both using the same mechanism (DKIM or SPF) for 
domain reputation, then the mechanism helps both. If they're not using the 
same mechanism, then neither is helped. In the absence of knowledge about 
which mechanism the recipient is using, the sender is wise to both DKIM 
sign, and to publish SPF records. In the absence of knowledge of which the 
sender is using, the recipient is wise to check both. Of course these 
scenarios are all determined by deployment choices that others have made. 
They're not inherent properties of the mechanisms.

Here's a table, where S is a sender who publishes SPF, D is a sender who 
DKIM signs. SD does both, but O does neither. Recipients are S if they 
check SPF records, D if they check DKIM signatures, SD does both, but O 
does neither. + indicates that some information is transferred from sender 
to recipient, - indicates that no information is transferred. As long as 
there are senders and recipients in all four categories, the people 
benefiting most from the available technologies are those that deploy both. 
Caveat: they have to deploy them sensibly.

Recipient:  O S D SD
Sender
O           - - - -
S           - + - +
D           - - + +
SD          - + + +

There's an analogy with blood groups, but the logic is inverted. With blood 
donations you want to avoid transferring information (antigens), except 
when the recipient doesn't have the antibodies that check for them.