Dear Stephen and Morris,
Regarding your first post, I do not see the kind of Digital Ocean problems that you have. In the past, I have had other problems, mostly a botnet that was trying to guess passwords for WordPress (nonexistent), for many months.
Concerning your second email, below, this has become a real sore point for me. However, I have no difficulty in identifying the recipients who are blocked. (I use Fedora linux with sendmail. That may or may not matter.) When a message from Mailman is blocked, I, as list owner, get a message that begins this way:
# From: Mail Delivery Subsystem MAILER-DAEMON@sjdm.org # To: jdm-society-bounces@sjdm.org # Subject: Returned mail: see transcript for details
I think this happens because I checked "yes" for all the boxes in the Mailman configuration for "notifications" under "Bounce processing". (I also checked "yes" for all notifications under "General options", but I don't think that is relevant here.)
The "transcript" says where the block came from, sometimes why the message was blocked (sometimes even with an address to complain to), and sometimes who the intended recipient was. (The bad news is that many of the addresses are not on my mailing list. They result from forwarding a listed address somewhere else, and the "transcript" doesn't give me the listed address. In a couple of particularly annoying cases I managed to track down the list member through detective work.) But it always gives the customer's address that is blocking the mail. Usually gmail will succeed in reaching that address if I want to tell the list member what is going on.
Some of the "Returned mail" is the result of "host not found" or "account does not exist", when, in fact, the host can be found or the recipient is easily reached by gmail. This problem seems specific to my mail system. Fortunately it is rare.
The other way I identify which users are blocked is that many of these are go into the "mail queue" (/var/spool/mqueue). As root, I am able to see all this with the "mailq" command, and each entry identifies the recipient. These are supposed to be temporary. The mailing system (sendmail) keeps trying to send these for 5 days. Most of them clear, but some never seem to clear.
I think what I have just said speaks to your question. If not, then I don't understand your question.
Now for a rant on the subject of spam blocking.
Many providers (including att.net) block what they guess is spam without letting the recipient know what is happening. This includes posts to a 4000-member Mailman list concerning the academic field of judgments and decisions. Sometimes the post itself has a "high probability of spam". Sometimes our server is blocked because it sends too much "spam", or because someone within one of our "ranges" of ipv6 addresses is sending what they call spam, or even because our provider, Linode, has been known to harbor spammers. Block lists vary a lot in how responsive they are to complaints. Most of them allow you to request removal, but that is not permanent. The worst two are Spamhaus CSS and UCEPROTECT3. Fortunately, nobody pays much attention to the latter. The documents for Spamhaus seem to say that they are doing this to force customers, like me, to put pressure on my provider, Linode, to prevent anyone from sending spam from their domain. They say that this is possible because Microsoft does it. (They seem to ignore the cost issue.)
Our server sees all the spam. (We use spamassassin to put it in a separate file.) 99% of it is simply electronic junk mail. If you had to sort it by hand, it would take a couple hundred msec to identify it and delete it, just like postal junk mail. By contrast, robo calls on a land line or cell phone are REALLY annoying. Thus, I do see why recipients cannot see the spam and create their own white list. Email spam is trivial by comparison. Gmail comes close to letting you decide what to call spam.
In sum, totally blocking "spam" from the recipient, on the basis of some fallible algorithm that guesses what is spam, is outrageous.
Jon
On 04/03/21 17:59, Stephen J. Turnbull wrote:
Morris Jones writes:
[AT&T are opaque about their standards and process, and don't provide any means to respond or unsubscribe their customers who don't want your mail.
This is the basic issue. Email users generally put more pressure on providers about "spam" (including stuff they've signed up for but have lost interest) than they do for lost mail (which they often don't know about, to be sure). Furthermore, with lost mail providers can easily point the finger elsewhere, which users tend to accept because moving providers is a massive PITA (unless the original one provides forwarding). Not much Mailman or site admins can do about this, unfortunately.
Note that in those cases where the provider sends examples of "problematic" mail from your server but redacts customer identification, there are ways to "fingerprint" the message which the providers usually don't touch. Basically, add a header field with a hashed email address. Of course this requires message-per-subscriber which may be costly, and won't do much good unless you see enough of these to make it worth doing this as a policy matter.
Since this involves patching Mailman anyway, you can add code so this only happens for specific problematic domains. It's reported to be effective with AOL and (IIRC) Yahoo!
Steve
Mailman-Users mailing list -- mailman-users@python.org To unsubscribe send an email to mailman-users-leave@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/