ietf-822
[Top] [All Lists]

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

2014-04-26 09:43:55
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
ietf-822(_at_)ietf(_dot_)org 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

_______________________________________________
ietf-822 mailing list
ietf-822(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-822