Thanks for the comments, Jon. Since this is not specific to solving a
current problem, I'm pruning all the personal addresses.
Jon Baron writes:
> I had this problem very badly after moving our server to the cloud
> (Linode), but not with this particular error message. At the beginning,
> most of the mail to any hotmail, outlook, live, ... address was
> rejected. Over a period of weeks,
Microsoft's spam filter is reasonably good at learning; you may simply
have established a good reputation in that length of time.
> A lot of this trouble came from ipv6,
I have no idea why that would be a problem with spam filters, unless
the problem is dynamic allocation, which this suggests:
> The solution to that was to get a proper ipv6 "range"
> with /64 at the end
> 1. Try to communicate with Microsoft.
This is always a good idea, not so always helpful, depending on the
vendor.
> 2. Some other sites that provide information that might help reduce
> bounces:
[omitted]
> 3. Set up DKIM and SPF. Dmarc was not necessary.
That's correct. Setting up DMARC may have other uses, but it can't
help you get your list traffic accepted.
The spf record has a piece especially for gmail. It looks like this:
> google-site-verification=E7LnfEhlLaYOfjeEzC2K-ylS4gctXNxge2BVz45y0XU
> v=spf1 +mx +a include:_spf.google.com ~all
> I'm not sure that the first line has anything to do with email. (We also
> have a web site.)
I don't know what that is, offhand. My guess it that it's some sort
of cookie saying you registered with Google, and that helps them track
your reputation. I'm pretty sure it is used for email since it's in
the place where SPF information is, but wouldn't be surprised if it is
used for other purposes as well.
> 4. In /etc/mail/sendmail.mc, define(`confMAX_HOP',`100')
This shouldn't affect whether other systems accept your list traffic,
only whether your system accepts incoming messages. I'm surprised
this is needed these days, although it's often the case that quite a
few hops can pile up as the message gets passed from a virus checker
to a spam filter to Mailman and back out again.
> 5. In /etc/mailman/mm_cfg.py:
> SMTP_MAX_RCPTS = 5
> (Some sites decide that mail is spam if too many emails come at the
> same time.)
I've never understood that, but I'm sure it happens.
> MAX_AUTORESPONSES_PER_DAY = 50
> (I'm not sure what this one does!)
This is possibly a bad idea. The idea is to prevent a mailbombing of
some innocent subscriber by the Mailman server through accident or
malice. It's hard to imagine why someone would offend Mailman more
than once or twice per day in ways that deserve an autoresponse to
each incident. I may go set mine to 5 (the default is 10)
If you ever send that many autoresponses to one mailbox in a day, I'll
bet your host gets permabanned from that provider.
> SUBSCRIBE_FORM_SECRET = [some string]
> (I'm not sure that this does anything, but it was recommended in
> Defaults.py.)
This prevents your subscription form from being used for cross-site
scripting (XSS), if I remember correctly. Being reported for an XSS
attack might hurt your general reputation but otherwise this is
invisible to your subscribers' providers.
> SUBSCRIBE_FORM_MIN_TIME = seconds(10)
> (This is supposed to stop bots. I'm not sure it does anything.)
It keeps out the script kiddies who aren't so up to date. This seems
like it might be long enough to annoy humans trying to subscribe. I
wouldn't make it longer.
> CAPTCHAS = {
> 'en': [
> ('What is two times six?', '(12|twelve)'),
> ],
> }
This is also invisible to subscribers' providers, but it can protect
your host from various kinds of mischief.
> 6. Prevented the use of digest on the list. I noticed that a large
> proportion of the bounces came from members who had chosen the digest
> format. I suspect that this had to do with the MIME encoding.
I don't think that's likely, although it's possible. Most mail
nowadays is MIME-encoded. More likely the problem is the boilerplate
in the header and table of contents, and there are likely to be a
*lot* of URLs for stripped attachments (if you set that).
> Probably there are ways to avoid having to [disable digests].
I imagine there are, but it depends on why it was necessary, if indeed
it was. :-) As you describe it it is *very* low-cost for your
subscribers so randomly ;-) disabling it to see if that helps is a
reasonable strategy.
> 7. Last but not least, many bounces resulted from "host not found"
> errors. This turned out to result from Linode's deficient
> nameserver.
Interesting. This is the first I've heard of this and I know a number
of satisfied Linode users.
Regards,
Steve
------------------------------------------------------
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/
