Grant Taylor via Mailman-Users writes:

 > Thus, recipients see that messages aren't coming from where the sender 
 > says they should be and that the cryptographic signature is broken. 
 > Hence the receiving server is naturally treating the message from the 
 > mailing list as highly suspicious.

"Naturally" if you don't read RFCs, of course.  There are *many*
common practices where mail comes from somewhere other than what From
says.  This is not limited to lists.

Normal folk of good will who hate spam (now, *that* is natural!) will
use code by developers who read the RFCs and know that a broken
signature has very little information compared to no signature at all,
and therefore SHOULD NOT (emphasis in the RFC) treat broken signatures
differently from absent ones.  Nowadays, you have to be *trying* to
break the Internet to treat broken signatures as significant.

 > To avoid this suspicion:
 > 1)  Send with your own SMTP envelope address (VERP).

I believe you can change the Return-Path using the list-bounces
address setting, but VERP doesn't affect the domain.  VERP adds a
cookie to the Return-Path which allows identifying the individual
recipients whose copies caused bounces.  As far as I know, the SMTP
MAIL FROM "envelope" address is set by Mailman from the list bounces
address.  I doubt there's a way to set it to the origin domain in
Mailman.

 > 2)  Use full personalization.

For many recipient domains, this won't help, because they'll identify
a mass-mailing by the Message-ID and/or content.  However, it may help
with some, either because they give spam points because it's not
personally addressed, or because they assess that personalization is
costly, so spammers won't do it.  (Both are bad ideas, but the average
user would break the Internet to avoid one spam per day, so there are
a lot of domains who do such things ....)

 > 3)  Remove incoming DKIM signatures.

Removing signatures you expect the list to break (by changing existing
headers or the body) is normally harmless.  However, if you have any
lists that make no changes at all to the existing header or body of
the message, but only add new fields to the header, you must not do
this for those lists.  You'll break all the AOL and Yahoo! users, and
possibly unsubscribe half the list.

Also, there are paranoid sites that try to reconstruct the original
mail by removing standard header tags and footers and attempting
validation.  This will break them.  (If that applies to your
recipients, they'll most likely let you know when you start removing
the incoming signatures, so it's not a significant consideration.)

 > 4)  Add your own outgoing DKIM signature.

This is always a good idea.

 > I'd suggest updating your config sooner than later.

When everything is an existential threat, nothing is an existential
threat.  But yeah, if there are delayable tasks, especially related to
mailing list admin, these checks and actions should be prioritized:
1.  outgoing mail is DKIM signed,
2.  with the right key,
3.  whose public key is in the right place in DNS, and
4.  if the lists are coming from a subdomain with a domain-wide key
    that the DNS record states that subdomains are covered, and
5.  fixing/adding any of the above that need it, and
6.  checking that the outgoing MTA's IP/domain is not on any
    blacklists and remonstrating with the owners if so, and
7.  adding/configuring/checking a spamcheck on mail incoming to
    Mailman, and
8.  if necessary exempting Mailman from any outgoing spamchecks (this
    doesn't help your mail get through, but the CPU will cheer).
Subscribers will appreciate it.

With lower priority, site admins whose lists are mission-critical may
want to sign up for various bulk mail certification programs (called
various things) at the Internet-scale providers like GMail, Microsoft,
and Yahoo!.[1]  Those require substantial effort, though.   There are
other ideas in the FAQ.

Steve


Footnotes: 
[1]  Unfortunately Yahoo! and AOL are now run by Verizon, which seems
to want to break the Internet, or at least Internet mail, so I suspect
their programs are losing usefulness rapidly.
------------------------------------------------------
Mailman-Users mailing list -- mailman-users@python.org
To unsubscribe send an email to mailman-users-le...@python.org
https://mail.python.org/mailman3/lists/mailman-users.python.org/
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/
    https://mail.python.org/archives/list/mailman-users@python.org/

Reply via email to