:: Re: [DNG] sender's address [was: Ke…
Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Bob Proulx
Fecha:  
A: dng
Asunto: Re: [DNG] sender's address [was: Keyboard scancodes, keycodes & etc.]
Gregory Nowak wrote:
> golinux wrote:
> > Nothing has changed. You have just noticed it perhaps because the number of
> > such occurrences has increased. However, maybe someone on this list will
> > know the answer because it is a common practice that I see on many email
> > lists.
>
> The short answer is DMARC. This was fully explained on this list way
> back when the change was first implemented. That message should still
> be in the list archives, try some time around 2016 I think.


A strict DMARC setting breaks mailing lists. This is by design of
DMARC which was intended to banks and financial institutions to allow
user sites to avoid phishing attacks. But this has been abused to be
used elsewhere and that causes trouble with mailing lists. Any user
mail sites which set a strict DMARC is abusing the design of it and
doing a disservice to their users.

A high security bank site never sends mail through mailing lists.
They want to ensure that their 2-factor email security tokens and
other communications are allowed directly from them to you with
nothing in the middle. Setting a strict DMARC allows mail user agents
to reject, discard, or file into SpamScam folders any mail forging
that high security site's email address.

Users on the other hand send email through mailing lists and send mail
to people who have set up forwarding and other very common things. In
that case a strict DMARC breaks mailing lists.

The Internet community might have been strict in return and created a
policy that senders with a strict DMARC would be blocked from sending
through mailing lists. Personally that is what I would have
preferred. Since it would have forced mail service providers to Do
The Right Thing or it would have forced users to select a different
mail service provider which did The Right Thing. But we the Intenet
community as a whole did not force the issue and instead worked around
it creating the current problem.

Working around it requires mailing lists to rewrite the sending
address to be the mailing list itself. That's what happens when you
see the someuser "via Dng <dng@???>" in the From: line.
It's a workaround. That means that the sender of that message is
using a strict DMARC which has explicitly stated policy not to use
their email address in a mailing list.

If you do not like this then peer pressure the sender to pick a better
email service provider which does The Right Thing and does NOT set a
strict DMARC policy. There is nothing any mailing list can do about
it, other than rejecting those senders entirely. Rewriting is a
workaround for their email's bad behavior with regards to mailing
lists which force the mailing list to use a workaround for it.

How is a strict DMARC set? Using a DNS TXT record. See the "reject"
policy set for example.com as an example. This is okay for
example.com which never sends any email and is useful as an example.
Try it with your own banking site domain.

    rwp@madness:~$ host -t txt _dmarc.example.com
    _dmarc.example.com descriptive text "v=DMARC1;p=reject;sp=reject;adkim=s;aspf=s"


What is a DMARC policy suitable for use in maiing lists? "none" is
the best policy for users who will be using mailing lists.

    rwp@madness:~$ host -t txt _dmarc.proulx.com
    _dmarc.proulx.com descriptive text "v=DMARC1; p=none"


    rwp@madness:~$ host -t txt _dmarc.gmail.com
    _dmarc.gmail.com descriptive text "v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-reports@google.com"


Not declaring a DMARC record is also not strict but many sites require
a DMARC policy declaration. Setting p=none is best for most people
who are not high security banks. Google has chosen correctly.

Mailing list management software such as Mailman not configured to
munge sender addresses when there is strict DMARC present have very
surprising and undesirable results which logically occur due to
handling a strict DMARC policy. If you ask me I will describe it but
will skip doing that here now because this message is already long.

Bob