Re: [ietf-822] one can re-sign without a permission to re-sign header

[Ned Freed <[e-mail]>]

s> On Wed 23/Apr/2014 00:13:15 +0200 Ned Freed wrote:
> > [...]
> >>> I know people think I'm wrong, but I think it needs to be looked at a
> >>> different way. As a recipient, I don't want 'proof' that this message
> >>> came from Alessandro, I want 'proof' that it came from the
> >>> [e-mail] mailing list.
> >
> >> I think you're right.
> >
> > I concur as well.

> Eh?  I agree a /receiver/ can do a better job by considering mailing
> list messages as an already filtered/moderated mail stream, rather
> than a collection of independent messages.  Talking domain-level
> authentication, even the local part is irrelevant.  As a /recipient/,
> however, the list where a message came from, ietf-822, ietf-smtp, or
> whatever, is a rather circumstantial attribute of a message.  I
> obviously care much more about who says what in which thread...

You're conflating completely different things here. We're talking about
assessing the validity of a message, not about the value of the content of
different valid messages.

And the fact is that essentially every mailing list I'm on - and I'm on a lot
of them run by a lot of different organizations - is very good at blocking junk
mail. As such, knowing that a message came from one of the lists I'm on - even
if I don't recognize the person posting or the topic they're posting about - is
more than enough to tell me that the message isn't garbage.

And not to be catty or anything, but this indicator is far more reliable than
getting a DKIM-signed message from, say, yahoo.com or aol.com. Indeed, on this
point, the SANS Digest had this to say about the situation at AOL:

  --AOL Locks Down Servers After Spam Deluge
  (April 22 & 23, 2014)
  Users have recently noticed a higher than usual volume of spam coming
  from AOL email addresses. AOL has now locked down its email servers to
  quell a spoof attack that is generating large quantities of spam. AOL
  has implemented a more stringent email validation process that instructs
  mailbox providers to reject email that appears to be associated with an
  AOL domain if the message did not originate from an AOL server. Reports
  also say that AOL Mail was breached and some accounts hijacked.
  http://www.theregister.co.uk/2014/04/23/aol_mail_locks_down_email_servers_to_deal_with_tsunami_of_spam/
  http://www.cnet.com/news/aol-imposes-stricter-email-rules-to-stem-spoofing-attack/
  http://threatpost.com/aol-email-hacked-by-spoofers-to-send-spam/105629   
  [Editor's Note (Murray): Received one from a neighbor and one from a
  family member on the same day.  I see these often enough that I have a
  standard reply.  "If you did not send the message below, your e-mail
  account may be compromised. Please change your password.  Recipients of
  your message who clicked on the embedded URL may have compromised their
  systems."]

Like Murray, I see these messages often enough that I have a standard reply to
them.

> >> I've said for years that lists should sign their mail with their
> >> own DKIM keys, and recipients should look at those list
> >> signatures to filter the mail.
> >
> > I'm not even sure that's necessary, but of course it can't hurt.
> > Indeed, right now, with the exception of IETF lists, having a
> > signature makes the odds it's spam more, not less, likely.

> SPF authentication covers most subscribers, but not those who have
> their mail forwarded to different sites (unless the forwarders use
> SRS).  DKIM signatures survive forwarding.

Sometimes they do, sometimes they don't. Depends on a lot of factors.

> Neither method is useful
> for DMARC because the domain being authenticated is that of the
> mailing list, which is aligned with "To:" rather than "From:".

> Is it possible to introduce "To:" as a _secondary identifier_ in the
> DMARC mechanism?  In that case a weak DKIM signature could be the
> element which authorizes receivers to use the secondary identifier.

Maybe, but I doubt very much this would be useful. Indeed, the reason we're in
this mess is because DMARC attaches semantic restrictions to the From: field.
Attaching more semantics to more header fields does not seem like a move in the
right direction to me. I'd much rather pursue Pete's approach.

				Ned