ietf-822
[Top] [All Lists]

Re: [ietf-822] WSJ/gmail/ML, was a permission to...

2014-05-03 15:31:45
On 05/03/2014 08:29 PM, Alessandro Vesely wrote:
On Fri 18/Apr/2014 14:37:21 +0200 John Levine wrote:
I also note that this hack, with or without Ale's changes, does
nothing to solve the send from gmail and WSJ article problems.
Those two problems can be solved in different ways.  Gmail could use a
third party's submission server just like they use its pop/imap one.
WSJ could write "WSJ.com" in the From: and the purported issuer in the
Subject: (and possibly also Reply-To:) instead of their currently
doing the other way around.

In your proposal one spam/phishing fighting technique (DMARC) requires (at least) three techniques to solve its problems (which in turn may require another 3^2 techniques to solve their problems, which ... 3^n techniques ... et cetera).


We need to refine the spec specifically for mailing lists.  I'd love
to read something like:

    A mailing list MUST NOT tamper with the From: field.  Those who do
    that are not mailing lists, and can work their own way out of
    DMARC.

Is it practical to mandate the same also for To:, Cc:, Date:?  Are
there lists which alter them?

Also:

    In order to get weak signatures, a mailing list needs to let its
    posters' domain admins know which posters post to which addresses.
    It is advisable to ask for posters' permission to do so.

That can be done manually for the time being.  Imagine lots of
ML-admins writing to the relevant postmasters asking to apply
low-profile signatures for specific MAIL FROM/RCPT TO pairs.  A
postmaster can verify that those users really post to those addresses,
and believe that it is a mailing list since its owner says so.  A
couple of scripts would do.  Automation can later be improved.

This really doesn't scale. Maybe you have the few TBTI ESP's in mind, of which there are only a few. But each domain that starts using p=reject will introduce a new set of relations (ML-admins-postmaster), which in turn will grow exponentially.


The same manual requests can be done for whitelisting, let's see the
pros and cons.

Either way, we have to do it at our expenses, since it's us who want
mailing lists.  Or we may hope that users' rebuttal will discourage
receivers from honoring DMARC policies, but that sounds like letting
email problems grow.

I agree there is a need to solve the current problems, but let's come up with one solution, not many.

/rolf

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

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