Re: [Asrg] where the message originated (was: DKIM role?) (SM)

--On 12 January 2009 12:58:28 -0500 der Mouse <mouse(_at_)Rodents-Montreal(_dot_)ORG> 
wrote:
> > However, I do think that it's time that domain owners started taking
> > responsibility for the use of their domains.
> If I, say, were to forge mail from your domain to, say, some ibm.com
> user, would you take responsibility for it?  That's what you seem to me
> to be saying.
Not quite, but not far off. I'm not taking responsibility for your decision 
to forge the domain. However, I AM responsible for the fact that IBM have 
no easy way to detect that forgery. I SHOULD accept that IBM are therefore 
more likely to bounce that email back to me.
   When a spammer forges my domain, and the recipient bounces the message,
   they're doing what SMTP is designed to do. I shouldn't get pissed off 
with
   the recipient, if I've failed to publish records that allow them to
   check for forgeries.

What I should take responsibility for is publishing records that let IBM 
easily check whether the email is legitimate. For example, if I publish SPF 
records, and sign all my outgoing mail with DKIM, and require my users to 
use my Message Submission Service, then I think I've discharged that 
responsibility.
Having taken those actions (actually, I haven't but this is hypthetical), 
I'm quite happy to accept any bounce messages from IBM - provided they've 
checked for an SPF or DKIM record match before accepting the message.
Now, given that I haven't yet published SPF or DKIM records, I still get 
lots of spam bounced into my domain. Who do I blame? Well, in part it's my 
responsibility for failing to help the spam recipients. If I did publish 
those records, then recipient domains could more easily detect forgeries 
out of my domain.
SPF records would be useful because you can check them early, and cheaply. 
DKIM give senders the opportunity to get messages through forwarders.
Now, what I'm suggesting (not advocating yet, because I'm not certain that 
this is right), is that when there's no SPF record published, that we 
should not feel too bad about bouncing email because the domain 
administrator isn't taking adequate steps to protect the domain against 
spam blowback, and against phishing. Of course, I'm NOT suggesting that 
lack of an SPF record should score very high in any any spamicity measure, 
but it might count for something.
Now, an SPF or DKIM match gives us the huge gain that we can bounce 
messages selectively based on the content. Some recipients may not want 
certain message content, but by the time we've seen the content SMTP 
doesn't allow us to selectively reject. And, a pass allows us to 
confidently whitelist a domain or sender address without opening up a huge 
hole in our spam defences. For example, I've refused to whitelist UK 
academic research boards because they don't publish SPF records.
Now, the question is, what do we do when we see an SPF softfail, and no 
DKIM record? Well, at first I'd be reluctant to bounce the message, because 
I want to reward admins that are taking steps to protect their domains. 
However, that's not something that I'd be happy with on a permanent basis. 
Eventually, I want the world to be in a position where all forwarders check 
SPF on the way in, and rewrite sender domains. When we're sufficiently 
advanced in that project, then bouncing softfail would be more acceptable.


> > In a world where you *can* prevent abuse of your domain, what's wrong
> > with bouncing email?
> Depends on what that prevention requires.  ("Sure you can prevent abuse
> of your domain.  You just need to enter into a bilateral agreement with
> every receiving mailhost on the net.")
No, you just need to sign your outgoing email, and publish SPF records.

I know, someone's going to tell me that SPF breaks forwarding. Well email 
is already broken. I get up to a million spam messages into my domain 
daily. Everything we do to prevent spam causes problems ranging from 
additional load on our DNS servers to loss of important emails. The 
question is, are we going to fix it? I think what I'm proposing would at 
least allow people to do safe whitelisting
--
Ian Eiloart
IT Services, University of Sussex
x3148
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg