ietf-asrg
[Top] [All Lists]

Re: [Asrg] DKIM role?

2008-11-20 09:34:11


--On 19 November 2008 16:56:37 -0500 Rich Kulawiec <rsk(_at_)gsp(_dot_)org> 
wrote:

On Wed, Nov 19, 2008 at 06:55:59PM +0000, Ian Eiloart wrote:
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.

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

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
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 mary(_at_)example(_dot_)com 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 mary(_at_)example(_dot_)com may be able to send traffic as 
john(_at_)example(_dot_)com,
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 mary(_at_)example(_dot_)com,
mary(_dot_)smith(_at_)example(_dot_)com, 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 mary(_at_)example(_dot_)com(_dot_)  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
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
https://www.irtf.org/mailman/listinfo/asrg



--
Ian Eiloart
IT Services, University of Sussex
x3148
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
https://www.irtf.org/mailman/listinfo/asrg

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