Hi,
I know there was a thread on this a few weeks ago, but I deleted those messages. My server has found itself, for no apparent reason, on AT&T's RBL. I've already written to abuse_rbl@abuse-att.net as suggested in the error message. I assume the upshot of the earlier thread was that all I can do is wait, possibly write again, and hope the AT&T RBL removal gods smile down upon me, is that right?
Thanks,
Jayson
On 3/30/2021 8:40 AM, Jayson Smith wrote:
I know there was a thread on this a few weeks ago, but I deleted those messages. My server has found itself, for no apparent reason, on AT&T's RBL. I've already written to abuse_rbl@abuse-att.net as suggested in the error message. I assume the upshot of the earlier thread was that all I can do is wait, possibly write again, and hope the AT&T RBL removal gods smile down upon me, is that right?
Same for me last week, for no apparent reason. They use up the full 48-hours they state before responding, but they did respond and delist my server.
They're opaque about their standards and process, and don't provide any means to respond or unsubscribe their customers who don't want your mail. I appreciate that from Verizon.
If I had to speculate, I would imagine them testing some new algorithms and processes, and discovering "false positives."
Best regards, Mojo
On 3/30/21 8:40 AM, Jayson Smith wrote:
Hi,
I know there was a thread on this a few weeks ago, but I deleted those messages.
This list has searchable archives at
https://mail.python.org/archives/list/mailman-users@python.org/. A
quick search for att bounce will find several posts in this (hijacked)
thread
https://mail.python.org/archives/list/mailman-users@python.org/thread/KSJX24CRPZOXDHSAKXC5QLHZAZA3LQFD/.
My server has found itself, for no apparent reason, on AT&T's RBL. I've already written to abuse_rbl@abuse-att.net as suggested in the error message. I assume the upshot of the earlier thread was that all I can do is wait, possibly write again, and hope the AT&T RBL removal gods smile down upon me, is that right?
I had two servers blocked by ATT, fortunately not this one. They were both DigitalOcean droplets, one hosts my bicycle club's lists and the other is my personal mail server. I didn't discover my personal mail server was blocked until I tried to notify the affected bicycle club people.
Anyway, I wrote to abuse_rbl@abuse-att.net separately about each block, and each time I wrote, I got the immediate autoresponse. For my personal server, after 62 hours I got a second message that they were removing the block and they did.
For the bicycle club's server, I wrote a total of 4 times over about 11 days before they finally removed the block. I had also suggested to the affected users that they could contact ATT. Out of 33 users, 2 changed to gmail addresses and 2 reported to me that they had contacted ATT, but from what I could understand from their reports, the ATT people they spoke with couldn't do anything and likely didn't even understand the issue.
The bottom line is you have no leverage. It's frustrating, but write every 48 hours and wait.
On 3/30/2021 9:28 AM, Mark Sapiro wrote:
I had two servers blocked by ATT, fortunately not this one. They were both DigitalOcean droplets,[...]
FWIW, a couple of my regular correspondents have said that DO generally does not have a great email reputation, and that they're moving lists to other platforms.
z!
On 3/30/21 9:33 AM, Carl Zwanzig wrote:
On 3/30/2021 9:28 AM, Mark Sapiro wrote:
I had two servers blocked by ATT, fortunately not this one. They were both DigitalOcean droplets,[...]
FWIW, a couple of my regular correspondents have said that DO generally does not have a great email reputation, and that they're moving lists to other platforms.
That's probably correct, but are there other cloud VPS providers that are better at hosting MTAs?
FWIW, mail.python.org which hosts hundreds of MM 2.1 and MM 3 lists including this one is a DO droplet. I do note that DO is currently listed at UCEPROTECT-Level3, but IMO, that's a racket. I.e. they list your hosts entire ASN ranges, but if your single IP is clean, they'll whitelist it for a price ranging from 25 CHF (about 26.50 USD) for 1 month to 90 CHF (about 95.50 USD) for 2 years
On 3/30/21 10:33 AM, Carl Zwanzig wrote:
On 3/30/2021 9:28 AM, Mark Sapiro wrote:
I had two servers blocked by ATT, fortunately not this one. They were both DigitalOcean droplets,[...]
FWIW, a couple of my regular correspondents have said that DO generally does not have a great email reputation, and that they're moving lists to other platforms.
To back that up, a great deal of the spam hitting my servers that clients make me aware of is originating from DigitalOcean IPs.
On 3/30/21 1:41 PM, Mark Sapiro wrote:
On 3/30/21 9:33 AM, Carl Zwanzig wrote:
On 3/30/2021 9:28 AM, Mark Sapiro wrote:
I had two servers blocked by ATT, fortunately not this one. They were both DigitalOcean droplets,[...]
FWIW, a couple of my regular correspondents have said that DO generally does not have a great email reputation, and that they're moving lists to other platforms.
That's probably correct, but are there other cloud VPS providers that are better at hosting MTAs?
FWIW, mail.python.org which hosts hundreds of MM 2.1 and MM 3 lists including this one is a DO droplet. I do note that DO is currently listed at UCEPROTECT-Level3, but IMO, that's a racket. I.e. they list your hosts entire ASN ranges, but if your single IP is clean, they'll whitelist it for a price ranging from 25 CHF (about 26.50 USD) for 1 month to 90 CHF (about 95.50 USD) for 2 years
I don't believe what AT&T is doing has anything to do with DO or any other cloud platform. The IP addresses of my Mailman servers (both 2 & 3) all have a IP reputation score of 97-99 with Senderscore.org and AT&T is still randomly blocks a server out of the blue. Linode is my cloud platform and they are also listed with UCEPROTECT-Level3 but no one uses that RBL to block email because what they are doing amounts to extortion.
Digital Ocean has a truly crappy reputation with us. We now block by IP address (knowing the problems) because of lack of cooperation from DO. Same for OVH. The email world would be better off without DO and OVH.
On 2021/03/30 11:33 AM, Carl Zwanzig wrote:
On 3/30/2021 9:28 AM, Mark Sapiro wrote:
I had two servers blocked by ATT, fortunately not this one. They were both DigitalOcean droplets,[...]
FWIW, a couple of my regular correspondents have said that DO generally does not have a great email reputation, and that they're moving lists to other platforms.
z!
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/
At Tue, 30 Mar 2021 10:41:47 -0700 Mark Sapiro mark@msapiro.net wrote:
On 3/30/21 9:33 AM, Carl Zwanzig wrote:
On 3/30/2021 9:28 AM, Mark Sapiro wrote:
I had two servers blocked by ATT, fortunately not this one. They were both DigitalOcean droplets,[...]
FWIW, a couple of my regular correspondents have said that DO generally does not have a great email reputation, and that they're moving lists to other platforms.
That's probably correct, but are there other cloud VPS providers that are better at hosting MTAs?
Almost certainly.
FWIW, mail.python.org which hosts hundreds of MM 2.1 and MM 3 lists including this one is a DO droplet. I do note that DO is currently listed at UCEPROTECT-Level3, but IMO, that's a racket. I.e. they list your hosts entire ASN ranges, but if your single IP is clean, they'll whitelist it for a price ranging from 25 CHF (about 26.50 USD) for 1 month to 90 CHF (about 95.50 USD) for 2 years
*I* have seen a lot of "spam" coming from DO IPs. Note this is "mostly" what might be called "E-Mail Marketing" and might be considered legit by some people, but I have been blocking /24 ranges of DO IPs.
On 3/30/21 1:50 PM, Robert Heller wrote:
At Tue, 30 Mar 2021 10:41:47 -0700 Mark Sapiro mark@msapiro.net wrote:
That's probably correct, but are there other cloud VPS providers that are better at hosting MTAs?
Almost certainly.
Any suggestions/recommendations?
On Tue, 2021-03-30 at 14:14 -0700, Mark Sapiro wrote:
On 3/30/21 1:50 PM, Robert Heller wrote:
At Tue, 30 Mar 2021 10:41:47 -0700 Mark Sapiro mark@msapiro.net wrote:
That's probably correct, but are there other cloud VPS providers that are better at hosting MTAs?
Almost certainly.
Any suggestions/recommendations?
Vultr, RamNode, and HostUS are solid ones.
-Jim P.
Hi Vince,
I thought OVH’s spam volume would reduce after one of their data centers in Strassburg burnt down - but it didn’t?
See, for example, https://www.reuters.com/article/us-france-ovh-fire-idUSKBN2B20NU.
:-(
Christian
Hilfe fuer Strassenkinder in Ghana: https://www.chance-for-children.org
At Tue, 30 Mar 2021 14:14:57 -0700 Mark Sapiro mark@msapiro.net wrote:
On 3/30/21 1:50 PM, Robert Heller wrote:
At Tue, 30 Mar 2021 10:41:47 -0700 Mark Sapiro mark@msapiro.net wrote:
That's probably correct, but are there other cloud VPS providers that are better at hosting MTAs?
Almost certainly.
Any suggestions/recommendations?
I have a cloud VPS at TekTonic (http://www.tektonic.net/index.html).
It appears that Mark Sapiro mark@msapiro.net said:
FWIW, a couple of my regular correspondents have said that DO generally does not have a great email reputation, and that they're moving lists to other platforms.
That's probably correct, but are there other cloud VPS providers that are better at hosting MTAs?
DO really is bad, and I block most of their IP ranges, poking the occasional hole for mail I really want.
There are better hosting providers. There are some that don't enable outgoing mail unless you ask and some that do some sort of filtering on outgoing port 25. I use tektonic.net which does the latter but the filters are mild enough that outgoing STARTTLS works fine.
R's, John
Carl Zwanzig writes:
On 3/30/2021 9:28 AM, Mark Sapiro wrote:
I had two servers blocked by ATT, fortunately not this one. They were both DigitalOcean droplets,[...]
FWIW, a couple of my regular correspondents have said that DO generally does not have a great email reputation, and that they're moving lists to other platforms.
DO hosts a large domain (appears to be a hosting reseller; don't recall offhand, if you want to know reply to me off list and I'll summarize to the list) that regularly tries to exploit my nonexistent O365 server and my also nonexistent DoH server, among others whose exact targets I don't remember offhand.
I wrote the domain once, got nothing, nothing changed. I've blocked a couple of /20s and even a /16 and I haven't seen DO for a few weeks. I also wrote DO once, got a thank you note, nothing visibly changed.[1] :-/
Steve
Footnotes: [1] To be honest, I'd already blocked the source address, but the only repeater I ever saw was my own employer's vuln scanner. :-þ What a PITA, 9000+ accesses as quickly as they could connect. During work hours (gggaaaah!) to boot.
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
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/
Jon Baron writes:
I think what I have just said speaks to your question. If not, then I don't understand your question.
It wasn't a question. It was a statement that a technical solution exists that might be useful to some site administrators in relatively unusual circumstances.
Now for a rant on the subject of spam blocking.
[ agreed! ]
In sum, totally blocking "spam" from the recipient, on the basis of some fallible algorithm that guesses what is spam, is outrageous.
And semi-popular with users while being cheap for providers, which was my other point. So, good luck doing anything about it. :-(
Let's put it this way: one of the few things my (ultimate) employer has done right in terms of Internet security was banning in April 2014 the use of Yahoo! addresses for communication within all educational institutions in Japan. And I haven't seen any (internally) since. :-) But it takes that level of power to do anything about sucky providers.
And ... uh, well ... they actually got it *wrong*: Yahoo! Japan franchised the name and some of the software, but otherwise is independent of international Yahoo!, and to this day
% host -t TXT _dmarc.yahoo.co.jp
_dmarc.yahoo.co.jp descriptive text "v=DMARC1; p=none; \ <= !!!!!
rua=mailto:ymail_dmarc_report@yahoo.co.jp"
This is the cockeyed Internet we have. It's wishful thinking to think otherwise. Im theory, it *could* be *much* better, but it's not going to "just happen". We have to build it ourselves. That's why we (Mailman) are here. Not that we're terribly important, or even all that good at it, but https://gitlab.com/mailman is open for merge requests if you can do a better job. :-)
By the way, that's a happy smiley, not a snarky smiley trying to imply "quitcherbitchin and code" or anything like that.
Steve
On 4/3/21 1:59 AM, Stephen J. Turnbull wrote:
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!
This is a feature in MM 2.1. From Defaults.py
# If the following is set to a non-empty string, that string is the name of a # header that will be added to personalized and VERPed deliveries with value # equal to the base64 encoding of the recipient's email address. This is # intended to enable identification of the recipient otherwise redacted from # "spam report" feedback loop messages. For example, if # RCPT_BASE64_HEADER_NAME = 'X-Mailman-R-Data' # a header like # X-Mailman-R-Data: dXNlckBleGFtcGxlLmNvbQo= # will be added to messages sent to user@@example.com. RCPT_BASE64_HEADER_NAME = ''
This feature doesn't yet exist in Mailman 3.
FWIW, Yahoo/AOL are not currently redacting the recipient address, but it may not be the address the message was sent to if intermediate forwarding is involved. Also, Hotmail is not currently redacting the recipient address. Personalizing deliveries and putting the recipient address in the msg_footer seems to work well for non-digest messages.
participants (13)
-
Brian Carpenter -
Carl Zwanzig -
Christian Buser -
Jayson Smith -
Jim Popovitch -
John Levine -
Jon Baron -
Keith Seyffarth -
Mark Sapiro -
Morris Jones -
Robert Heller -
Stephen J. Turnbull -
Vince Heuser