ietf-dkim
[Top] [All Lists]

RE: [ietf-dkim] Re: ISSUE 1521 -- Limit the application of SSPtounsigned messages

2008-01-24 15:11:17
 
I don't want to get too far afield with respect to SPF. This is after
all the DKIM list. I will submit a single post on this topic because I
believe it bears on the discussion at hand. Why a MUST check for From is
needed for the case of signed by 3rd party but not signed by From domain
- without requiring any particular action based on that check.

At some future point I'll provide SPF related information from our
implementation experience on the SPF-discuss list

-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org 
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Steve Atkins
Sent: Thursday, January 24, 2008 3:22 PM
To: ietf-dkim WG
Subject: Re: [ietf-dkim] Re: ISSUE 1521 -- Limit the 
application of SSPtounsigned messages




Sounds like interesting operational data.

Absolutely and at some future point I want to share what we are seeing
with a wider audience. It's still too early to get too detailed as we
are still looking at and working through the data.

Could you expand on your choice to use ~all for ag.com - 
presumably important corporate mail - while using -all for 
americangreetings.com - presumably bulk/junk/e-card mail?


Absolutely. 

People primarily receive greeting card notification and confirmation
email from americangreetings.com (and other brand domains of ours).
While some people may have an axe to grind about online greetings, a lot
of senders and recipients consider them inportant. People use them for
birthdays, anniveraries, births, deaths and all sorts of other events.
This is why the bad folks abuse greetings for phishing/malware. People
want to be loved. It's pretty much hard wired. In that respect
protecting americangreetings.com and the people who receive email from
that domain is much more important than ag.com - the effort directly
impacts millions of people. 

In the past, like other social expressions sites, these domains have
been subject to heavy abuse through fraudulent emails. The general
solutions were reactive. Using -all provides an opportunity for
receivers to protect their users from fraudulent emails by checking the
Mail From against our SPF records. For those domains we know that emails
should be originating from somewhere else. We had weaker assertions for
quite some time. We were changing our internal processes to take
advantage of -all. We are now in a position to do so with some level of
confidence. I hope that as we are able to share our experience it will
build confidence in others that the rewards far outweigh the risks and
justify the effort to architect or re-architect implementations that
support strong assertions for both path based and message based
authentication.

Similar issue for DKIM signing. We don't consider it a strong enough
practice to sign just some of the email from the website domains. It is
important to provide a clear statement to both receivers and end users.
We want to be able to tell people that all email for
americangreetings.com is signed. No waffling, no I'm not sure or maybe.
By indicating uncertainty one invites abuse. This is why I'm passionate
about requiring checks for the From field. It protects people in
significant use cases.

The reason that ag.com uses ~all is simply that it involves a more
complex use case. There are actual real users and user accounts instead
of role accounts. People travel. We have acquisitions. I have a high
confidence that we could move to strong assertions with few problems. I
just have to find the cycles to prepare for and deal with those few
problems (that may take a lot of time to address for non-technical
reasons) once we throw the switch. 

It's not as easy for me to work with receivers on mail from ag.com
because it isn't high volume and it is not a general abuse situation for
their constituencies. Feedback is mighty useful in moving forward on
this stuff. This isn't a complaint, simply a recognition of reality.

It simply isn't as easy to take the stronger stance for the corporate
domain and be comfortable that there aren't negative impacts. There are
more factors for the corporate domain that I need to build consensus and
buy in for. 

It took a lot of work for us to reach the point of strong assertions for
the website domains without these sorts of issues. I do want to point
out that the steps that PayPal took with Yahoo! and the information they
presented on the low rate of false positives built a lot of confidence
on our part. Our experience with implementing strong assertions for the
website domains should build confidence for implementation for ag.com.

I'm looking forward to the day we can assert -all for ag.com and every
single domain that we control. 

With respect to DKIM, there is one use case where use of strong SPF
appears to be very advantageous. If you wish to determine that all your
outbound email for a domain is truly signed with DKIM, having a strong
SPF assertion and receivers that can give you feedback will allow you to
identify if you have any "leaking" email that is not signed. We know
where we are signing. We had one small case of leakage that was quickly
identified and resolved. This gave us a very simple equation. 

known signing points within our IP Address range VS other IP addresses
in our IP Address range VS hosts not within out IP address range.

I would recommend using t=y for your signing as you try to get to the
point that you are sure that you are signing everything. 

Also, were there any interesting delivery rate changes when 
you changed your SPF practices?


We generally have always had good delivery. That isn't why we are taking
the steps we are taking. The general answer to your question is that we
have not seen negative impacts on delivery rates from making a strong
assertion. More detailed than that I'm going to have to hold off until a
later point. I think this outcome is specific to our case and may not
predict outcomes for other implementations. If a sender is perceived by
receivers as a problem, strong authentication makes it easier for the
receiver to block or drop their messaging. And that is as it should be.

Mike


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

<Prev in Thread] Current Thread [Next in Thread>