Subject: [Asrg] DKIM role?

From: Franck Martin <[email-masked]>
Date: Wed, 19 Nov 2008 18:05:17 +1200 (ANAT)

In fact the only thing that dkim is bringing with certainty, is that you can send replies to the enveloppe, if you have classifed the e-mail as spam, found a virus, etc.. Usually this process is suppressed because spam and viruses emails include fake headers. 
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: Rich Kulawiec <[email-masked]>
Date: Wed, 19 Nov 2008 07:13:00 -0500

On Wed, Nov 19, 2008 at 06:05:17PM +1200, Franck Martin wrote:
> In fact the only thing that dkim is bringing with certainty, is that you can send replies to the enveloppe, if you have classifed the e-mail as spam, found a virus, etc.. 

But you shouldn't do this (send replies), for multiple reasons.  First,
at a strategic level, anything that generates still *more* mail traffic
when we already have way too much seems like a bad idea.  (This is one
of many problems with C/R and SAV s well.)  And at a tactical level,
what would be the point?  There's no way to know that such a reply will
ever be seen by the end user whose system has been zombied, and even if
they *do* see it, it's very unlikely they'll understand it, believe it,
and take effective action.

---Rsk

---

From: Franck Martin <[email-masked]>
Date: Thu, 20 Nov 2008 00:16:22 +1200 (ANAT)

but all MTA's send NDR, this is part of their role? or should we stop that? 

----- Original Message ----- 
From: "Rich Kulawiec" <[email-masked]> 
To: "Anti-Spam Research Group - IRTF" <[email-masked]> 
Sent: Thursday, 20 November, 2008 12:13:00 AM (GMT+1200) Auto-Detected 
Subject: Re: [Asrg] DKIM role? 

---Rsk

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 19 Nov 2008 07:13:32 -0600

Rich Kulawiec wrote:
>> In fact the only thing that dkim is bringing with certainty, is that you
>> can send replies to the enveloppe, 
...
> But you shouldn't do this (send replies), for multiple reasons. 

Only one:  DKIM does not assert that any address in the message is valid.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: Rich Kulawiec <[email-masked]>
Date: Wed, 19 Nov 2008 08:33:34 -0500

> but all MTA's send NDR, this is part of their role? or should we stop that? 

The latter.  There's no point in sending a NDR in response to malware
or spam (and many reasons not to).  Just reject it outright during
the SMTP conversation, and let the sending system deal with that.

Think about this way: if it's malware, then either the connecting system
originated it or is forwarding it.  If it's the origin, then it's enemy
territory and there's no point.  If it's forwarding malware, then there's
no point in trying to forward a response back to the originator because
it's the keepers of the forwarding system who need to know.

If it's spam, then similar reasoning applies: if it's the origin,
then you're telling spammers that they're spammers, which they already
know.  If it's forwarding spam, then it's the keepers of the forwarding
system who need to know, not the putative originator.

This applies no matter what authentication technology (if any) is in
place, even hypothetical authentication technology which identifies
the original sender.

---Rsk

---

From: Seth <[email-masked]>
Date: Wed, 19 Nov 2008 10:45:11 -0500 (EST)

> but all MTA's send NDR, this is part of their role? or should we

Sending them to *local users* (e.g. Panix.com telling me that I sent
to an invalid address) is useful and non-abusive.

Sending them to *unknown and probably forged* remote users is abusive.

Seth

---

From: Michael Thomas <[email-masked]>
Date: Wed, 19 Nov 2008 08:09:37 -0800

> place, even hypothetical authentication technology which identifies

Murray at sendmail has proposed a new draft which (I hope I'm
characterizing this correctly -- it's been a while) would provide
a feedback mechanism for authentication failures. IIRC, it's not
a NDR but something else. The general idea was to attach this "report
back to me" feature in the ADSP record, with some sort of standardized
report sent over SMTP.

We decided to defer any work on that as -- as this post rightly
points out -- it is a huge can of worms, and that if not thought
out completely could be quite harmful. But it would be nice for
signers to have some idea somehow if their signatures were being
broken. Like, for example, if somebody were spoofing their addresses
they might be able to hunt them down. Or just the simple non-malicious
fact that most reasonable sized organizations have clue-0 who is
actually sending legitimate mail on their behalf.

I believe that the DKIM wg is in the process of rechartering, and
that this was proposed as possible wg item. My feeling is that the
the problem and possible solutions are not well defined, and that
it's not entirely clear that DKIM is the right place for it.. yet.
As a research-y kind of thing, however, it does seem to have merit
at least understanding the problem space, IMO.

		Mike

---

From: Ian Eiloart <[email-masked]>
Date: Wed, 19 Nov 2008 18:55:59 +0000

> the SMTP conversation, and let the sending system deal with that.

Agreed, but the OP's point was that such a reply (which may be unrelated to 
the message source or content) can be sent if you're sure the message was 
sent by the owner of the envelope sender - ie with a DKIM pass.

-- 
Ian Eiloart
IT Services, University of Sussex
x3148
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: Rich Kulawiec <[email-masked]>
Date: Wed, 19 Nov 2008 16:56:37 -0500

On Wed, Nov 19, 2008 at 06:55:59PM +0000, Ian Eiloart wrote:
> Agreed, but the OP's point was that such a reply (which may be unrelated 
> to the message source or content) can be sent if you're sure the message 
> was sent by the owner of the envelope sender - ie with a DKIM pass.

But (a) that doesn't mean it was really sent by the user and
(b) it still doesn't serve any useful purpose.

Let's put aside (b) for the moment and focus on (a).  One of the things
I've noticed about quite a few mail servers over the past several years
is that while an increasing number of them are moving to require user
authentication (even when sending from networks local and known to
the mail server) that (1) many don't and (2) some which do don't force
the envelope-sender to match the authenticating user.  In the case of (1),
many mail servers still seem to allow submission from local/known networks
with no authentication...which in turn means that any system on those
networks can send mail as any user known to the mail server, which in
turn means that a batch of spam purportedly from [email-masked] may
not have anything to do with mary or mary's system.  (Note that malware
resident on any end-user system local to mail.example.com is likely to
find a sizable list of users to choose from simply by rummaging through
the contents of disk.)  In case case of (2), a system authenticating
as [email-masked] may be able to send traffic as [email-masked],
depending on its capabilities and configuration.  (I'm aware of a number
of variations on this, including one site that deliberately left this
open in order to allow mary to send as [email-masked],
[email-masked], etc., and is counting on their post-processing
of logs to detect any exploitation of it.)

In neither case will sending traffic back achieve anything useful.

And note that even if both these problems are solved, there is still
nothing to stop malware resident on mary's system from authenticating
and sending spam as [email-masked].  And again there is still no
point in sending a stack of NDRs to mary's account: either the malware
will let her see them or it won't.  (e.g. it wouldn't be that hard
to craft malware that connected to mail.example.com via IMAP and
deleted everything that looked like an NDR.  Even sloppy code would
be good enough -- so what if it deletes too much?)  If the malware
won't let her see them, then there's no point in sending them.  If the
malware *does* let her see them, what will this achieve?  What will mary
do when faced with 50,000 NDRs?

And note that all of this just gets worse when quarantining and mail
quotas are factored in.  (Which should not be taken as support for
either on my part: I think both are very bad ideas.)

---Rsk

---

From: Ian Eiloart <[email-masked]>
Date: Thu, 20 Nov 2008 14:33:51 +0000

--On 19 November 2008 16:56:37 -0500 Rich Kulawiec <[email-masked]> wrote:

> Let's put aside (b) for the moment and focus on (a).

The only thing that matters is that you can reach the system administrator 
for the domain that sent the email.  Then you can assign reputation to the 
domain, and even to the email address used. What happens from there on is 
down to local policy - it'll depend on whether the domain belongs to an 
ISP, a university, an individual, or whatever. But, you'll be able to hold 
the domain admin responsible for the email. If the domain is well managed, 
then users will be able to benefit from personal reputation scores for 
email address that they own - otherwise they'll suffer according to the 
behaviour of their peers.

A domain administrator will then be under a fair amount of pressure to sort 
out all the problems that you list below, such that domain users don't 
suffer from bad behaviour of their peers in the domain.

All of which means that DKIM, or something like it, is a necessary but not 
sufficient condition to be able to eventually assign reputation to a sender 
address. DKIM isn't the destination, but it's a road that we need to travel 
along.

> One of the things

---

From: Rich Kulawiec <[email-masked]>
Date: Sat, 22 Nov 2008 08:43:21 -0500

On Thu, Nov 20, 2008 at 02:33:51PM +0000, Ian Eiloart wrote:
> The only thing that matters is that you can reach the system 
> administrator for the domain that sent the email.  Then you can assign 
> reputation to the domain, and even to the email address used.

But you can do that today -- well, by IP address, at least, which is
(as we've seen from the use of DNSBLs) nearly always good enough to
make accept/deny decisions WRT email.

And *please* let's not try to assign reputations to individual email
addresses, as the scalability problems involved in N users with M email
addresses trying to track reputations of N users with M addresses,
given that N is on the order of 10e9, are awful.

> happens from there on is down to local policy - it'll depend on whether 
> the domain belongs to an ISP, a university, an individual, or whatever. 
> But, you'll be able to hold the domain admin responsible for the email. 

I see what you're saying but we can do this *today* by IP address (and
thus by extension) by network.  In fact: we ARE doing it, and have been
for a long time.  It works quite well, without the need to invent and
deploy any new technology.

Given that it's trivially easy to change domains (spammers go through
them by the thousands, and ICANN seems quite intent on making this even
easier and cheaper for them) but much more difficult to forge IP addresses
and change networks, it seems much better for anti-spam purposes to
focus on addresses and networks, and not on domains.

But there's a more fundamental problem at work here.

We have to take into account the presence of a few hundred million
0wned systems -- whose new owners have the ability to immediately take
possession of any authentication credentials used on them, should
it please them to do so.

So although we frequently refer to spam as "the problem", it's not
the problem -- it's merely a symptom of the problem.  The problem is
a serious and fundamental lack of security on a very large number of
network endpoints.  That problem remains unaddressed except in token
fashion, which is why it continues to get worse with no sign
of any turnaround in the forseeable future.  (And multiple signs that
it could get much worse, i.e., the inclusion of DRM in popular OS
releases, meaning they're pre-compromised at the factory, so to speak.)

Sure, we could argue "go ahead and do it anyway", but I think that's
not a good idea.  The enemy reads these lists and the RFCs and the code, too,
and has long since demonstrated the capacity to wait until something's
deployed, then begin to exploit it.  This is, by the way, one of my
deep concerns with anti-forgery technologies: it's my opinion that
widespread deployment of one will be followed shortly thereafter with
widespread exploitation: see "few hundred million 0wned systems" above,
and note that the absence of any reason to think that corporate or ISP or
government or university or any other networks are free of these.
I'm worried that if we begin deploying technology that trains users to
believe that email is REALLY from who/where it claims to be from, that
they will eventually accept that training...at which point forgeries
become much more dangerous than they are now, when we're training users
never to believe that anything is from who/where it claims to be.

---Rsk