[Asrg] DKIM role?

[Ian Eiloart]

--On 19 November 2008 16:56:37 -0500 Rich Kulawiec <rsk at gsp.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.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.com may be able to send traffic as john at example.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.com,
> mary.smith at example.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.com.  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.org
> https://www.irtf.org/mailman/listinfo/asrg



-- 
Ian Eiloart
IT Services, University of Sussex
x3148