Re: [mailop] One click unsubscribe in mailing list messages
Greetings, * Slavko via mailop (mailop@mailop.org) wrote: > Dňa 25. februára 2024 3:10:51 UTC používateľ Philip Paeps via mailop > napísal: > > >Not being able to present information in the Subject: or body clearly isn't > >ideal, but it's better than breaking DKIM. List-* headers have been in > >widespread use for over twenty years. > > The bad part is, that eg. exim by default (over)signs List-* headers > nonexistence, thus adding them will break its DKIM anyway. We (postgresql.org) are similar to the FreeBSD folks in that we don't modify the body or the Subject line, so as to avoid breaking DKIM. Further, emails which over-sign the List-* headers are moderated and rejected when they hit our lists and we tell people to go fix their configuration. > I don't know how many exims (providers) uses that default, but our > job's email provider do that. When i complained, i got response, that > it is right and i do not understand DKIM... :-D It's certainly unfortunate that there are some folks who insist on using exim's default (which is also the recommendation from some RFC which is very annoying). We've been able to have some success getting people to fix things as, otherwise, they can't post to the PG mailing lists. Not sure if that would be helpful to mention to your provider but who knows, maybe it would be.. Thanks, Stephen signature.asc Description: PGP signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is forwarding to Gmail basically dead?
Greetings, * John Levine via mailop (mailop@mailop.org) wrote: > According to Marco Moock via mailop : > >Because they already have Gmail and use the App or are satisfied by > >their webmail. > >Some people don't want to set up a client because they think it is too > >complicated. > > Some of my users have trouble forwarding to Gmail because their > correspondents use only SPF, not DKIM. Agreed- this is an issue and we've seen it too. I've ended up having to suggest to some that they remove their SPF DNS entries as that actually ends up helping with deliverability, which seems odd but is, in fact, true. Frustratingly, some see DKIM as too complicated and they run their own mail servers and simply won't set it up. I agree that it's annoying to do ... but it's become pretty close to necessary these days. Thanks, Stephen signature.asc Description: PGP signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is forwarding to Gmail basically dead?
Greetings, * Jarland Donnell via mailop (mailop@mailop.org) wrote: > Aside from the question in the subject, because I see this brought up a lot > on the mailing list in relation to email forwarding, would passing ARC > signatures even matter when the problem is that Google is increasingly > rejecting forwarded emails due to the DMARC policy of the original sender > domain? I've not seen ARC make much of a difference. What does make a difference is making sure that your forwarding doesn't break the DKIM signature. If it's going through a mailing list then you need to make sure that the incoming DKIM sigs don't over-sign the List-* headers (frustratingly, there are some systems out there with a configuration that includes over-signing of List-* headers, as it's the default in some MTAs). We've implemented checks to moderate/refuse inbound emails to our lists which will fail DKIM once passed through the list and having the List-* headers added. Overall, we have good success delivering to gmail when there's a valid DKIM signature from the original domain. > We've had great results for a long time just using SRS. I know how some of > you feel about it, but using the tools in front of me, SRS has done the job. > But now that Google is pushing DMARC harder, more and more domains are > setting their DMARC policy to reject, and Google appears to at least be > enforcing this more than before. From the look of it, we can no longer > forward emails from Yahoo to Gmail: > > 550-5.7.26 Unauthenticated email from yahoo.com is not accepted due to > domain's DMARC policy. Please contact the administrator of yahoo.com domain > if this was a legitimate mail. To learn about the DMARC initiative, go to > https://support.google.com/mail/?p=DmarcRejection > ev25-20020a056808291900b003be1cb5a890si971207oib.250 - gsmtp Our success includes inbound emails from yahoo.com which are able to pass through our mailing lists and get delivered successfully to gmail.com addresses. > Is it time to throw in the towel on email forwarding? Nearly 100% of users > who forward email do so because they want it in Gmail. POP3 fetch has it's > own concerns (local to local mail imported over POP3 fails SPF on import and > gets filtered to spam). I'm quite skeptical that ARC fixes anything but > theory and how people wish it was (or hope for it to be) trusted. If your forwarding is breaking the DKIM signature then that's the first thing to work on fixing. If you're already ensuring that DKIM isn't broken then perhaps there's other things to look into, but that's definitely the first thing to check. Thanks, Stephen signature.asc Description: PGP signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] Recent increase in GMail 421-4.7.28 responses
Greetings, For about the past month we (PostgreSQL.Org mailing lists) have seen a large increase in the number of 421-4.7.28 "Our system has detected an unusual rate of unsolicited mail originating from your IP address." responses when attempting to deliver to gmail.com addresses. This is creating a painful backlog of queue'd email for us, not to mention gmail.com users having email from our lists delayed for hours and days in some cases, something we've not had issue with for years prior to this. We are delivering from: malur.postgresql.org has address 217.196.149.56 malur.postgresql.org has IPv6 address 2a02:16a8:dc51::56 Which is listed in https://www.dnswl.org/ as high trust, our mailing list software specifically avoids DKIM corruption, we provide List-Unsubscribe (along with other List-* headers), and all subscribers have to go through a process of creating a postgresql.org account (with email address verification as part of that process) before they can subscribe to any of ours lists. We've also been delivering a simiar amount of email to gmail.com addresses for many years without this issue. We have seen some emails coming through which fail DKIM due to over-signing of the List-* headers or incorrect DKIM configurations. We've reached out to those individuals to work on correcting their DKIM configurations and have implemented code changes to catch and moderate and bounce back email that either fails DKIM or would fail it when posted to our lists. We're also working on removing email addresses that have been bouncing back to us due to 'over quota' responses from gmail for long time (even though the 4xx codes would have one believe that this is a situation which will eventually correct itself... we've seen many cases where it doesn't for months...). Based on our review of GMail's documentation, however, these actions do not seem very likely to actually change things. We've also reviewed what GMail publishes regarding reported spam from our IP and it's literally 0%. Since implementing the changes described above a few days ago, very few emails that fail DKIM have passed through our lists, the one exception being a few Twitter emails going to closed lists with very few people on them. Ultimately, we feel fairly comfortable saying that whatever changed a month ago certainly didn't seem to be due to these few DKIM failing emails. We're investigating other changes such as possibly spinning up a separate dedicated server to deal with email destined for gmail.com (or perhaps we'd move everything *else* to the new system/IP) but this is certainly far from ideal when we have historically had a very smooth running and fast system prior to this past month. Thanks! Stephen PostgreSQL.Org Sysadmin team signature.asc Description: PGP signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] United Airlines / mileageplus DNS/rDNS mismatch issue
Greetings, I'm getting some inbound email attempts that I believe are legitimate from United Airlines that are being rejected due to: May 9 12:55:38 tamriel postfix/smtpd[1221960]: warning: hostname o1.email.smallbusiness.mileageplus.com does not resolve to address 50.31.61.242 Tracking this back, near as I can tell, postfix is correct here in that 50.31.61.242 / 242.61.31.50.in-addr.arpa resolves to o1.email.smallbusiness.mileageplus.com but o1.email.smallbusiness.mileageplus.com doesn't seem to actually exist: dig o1.email.smallbusiness.mileageplus.com a ;o1.email.smallbusiness.mileageplus.com.IN A ;; AUTHORITY SECTION: smallbusiness.mileageplus.com. 600 IN SOA vndcdf-fs-gma3-vip.ual.com. ualipconfig.united.com. 40 10800 3600 2592000 600 Hopefully someone on here is from UA or knows how to get in touch with someone there who could like into fixing that. Thanks, Stephen signature.asc Description: PGP signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Mailing Lists and domains with DMARC reject
Greetings, * Slavko via mailop (mailop@mailop.org) wrote: > Dňa Mon, 6 Mar 2023 17:41:45 -0500 Stephen Frost via mailop > napísal: > > > I was interesting in this, thus i log DKIM signed headers list (not > > > from ML) for some weeks, oversigned List-* headers are not common, > > > but happens. > > > > I'm curious where it does happen and isn't actually from a mailing > > list.. The List-* header would presumably be empty in that case and > > yet still included in the signature? I realize it's possible but ... > > ugh. > > I agree and i consider this as "ugh" too. IMO if message is not from ML > these headers does not construct core of message ;-) > > Initially i noticed it in my job's email. I didn't see server config > nor know its signing software, thus i can guess only, but IMO it comes > from exim -- i roughly remember that from some headers in past. > > By default exim (4.94) uses this list of headers to sign: > > > ...:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive > > That means, that exim signs all occurrences (not over sign) and > nonexistence of these headers. exim provides second list of headers, it > is exactly the same, but over signs all these headers, thus things are > the same (in this topic). That means that in both default cases, all > these headers are always included in signature. > > Try to guess how many exims uses one of these defaults? IMO, that will > not be negligible... I just went through and did a review of a few years of email to the PostgreSQL mailing lists and while it wasn't completely scientific (using grep mainly and not some proper processing), I found only two messages that arrived to any of the lists that I'm on (which is all the big ones and most of the others) that had a 'List.*' header in a 'h=' line and one of those was clearly a bit of spam that got through. Certainly doesn't seem to be a common issue. Thanks, Stephen signature.asc Description: PGP signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Mailing Lists and domains with DMARC reject
Greetings, * Slavko via mailop (mailop@mailop.org) wrote: > Dňa 3. marca 2023 17:03:35 UTC používateľ Jesse Hathaway via mailop > napísal: > >2. Preserve the original DKIM signing of the message by only adding > >additional headers, i.e. do not modify the subject or add a trailer > >message. This is what we do (for lists hosted on lists.postgresql.org). > This one will work only if sender doesn't oversigns List-* (or any other > added) headers, and some domains does it in regular mails... We've seen very very few (I'm not sure I specifically recally any..) List-* oversign cases. If we got those, I suspect we'd probably disable that user and ask them to try and fix their email system. > I was interesting in this, thus i log DKIM signed headers list (not from > ML) for some weeks, oversigned List-* headers are not common, but > happens. I'm curious where it does happen and isn't actually from a mailing list.. The List-* header would presumably be empty in that case and yet still included in the signature? I realize it's possible but ... ugh. * Mark Fletcher via mailop (mailop@mailop.org) wrote: > On Fri, Mar 3, 2023 at 9:21 AM Jesse Hathaway via mailop > wrote: > > 1. Rewrite the RFC5322.From address to be an address from the mailing > > list domain, place the original RFC5322.From address in the Reply-To > > header. Sign the message with the mailing list's DKIM key. > > This is what we do. Our users nearly rioted at this idea, for good reason, imv. > 2. Preserve the original DKIM signing of the message by only adding > > additional headers, i.e. do not modify the subject or add a trailer > > message. > > This was never an option for us, as our users want a subject tag and > including a footer with an unsubscribe link is table stakes for a mailing > list. Not being able to have an unsubscribe link is annoying but we've been pretty successful having a List-Unsubscribe header that a lot of mail clients recognize and will utilize to make a button to perform the unsub using. Getting that to happen on more would be interesting to us- if anyone has info about how to specifically do that, please feel free to pass that along. > > Does anyone have any knowledge on which methodology is the most > > successful for ensuring delivery. > > I can't tell you if #2 ensures better delivery, but even doing option #1 > gotchas abound. Many domains, regardless of DMARC policy, do not like it if > you send them an email with an RFC5322.From containing their own domain, > for example. All messages to Outlook 365 domains need their > Froms re-written. Many Exchange servers are set to silently drop messages > unless you re-write From lines. On several occasions I have considered just > re-writing ALL From lines, regardless of DMARC policy, but that is really > not wonderful and when asked, our users were against that idea. Only see one obvious office 365 user on our lists and their domain (as this would be domain specific, no..?) doesn't have a DMARC policy. That said, I do feel like we have pretty good delivery using approach #1. Admittedly, we aren't as big as others and our users are pretty technical. I'm fairly confident we deliver to a lot of exchange servers though successfully and looking at domains that end up delivered to outlook.com servers, there's certainly some with DMARC reject policy that we successfully deliver to without any rewriting of the RFC5322.From address. > It's a maze of twisty little passages... Indeed. > We have to keep a list of domains that require special re-writing, which is > updated by hand when people complain about deliverability issues. ... ew. Thanks, Stephen signature.asc Description: PGP signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] free.fr / tdsnet.com / zeelandnet.nl bounces
Greetings, On Sat, Aug 7, 2021 at 07:54 Stuart Henderson wrote: > On 2021/08/06 11:31, Stephen Frost via mailop wrote: > > Greetings, > > > > We have quite a few folks with @free.fr addresses, and a few with the > > other domains listed in $subject, on the @postgresql.org mailing lists > > and recently we've started getting bounces back for some of the emails > > we send out, claiming they're spam (which they certainly aren't). > > > > If this continues, we're going to have to unsubscribe them all, but > > figured I'd reach out here first to see if there's any free.fr admins > > (or those for the other domains, though we have just a few of those) > > paying attention who could help us figure out why these emails are being > > classified as spam and help us work to a resolution. > > > > These emails from coming from 217.196.149.56 / > > 2a02:16a8:dc51:0:0:0:0:56, SPF matches, DKIM signed, passes DMARC, etc. > > Our best guess is that the ones being marked as spam have too many URLs > > or some other silly measure that's tripping up a poorly designed spam > > filter. > > Whether a message passes DMARC or not depends on the From: address in > the email headers. Unless you rewrite that (which looking at the archives > it doesn't appear you do) you'll see rejections from some sites if that > domain publishes a p=reject policy. Could it be due to that? The bounces are pretty much exclusively from our announce mailing list, where we do force a From: address that’s under our postgresql.Org domain. Here’s an example from our archives that was bounced for being “spam” (though only from the few domains listed above, and we deliver to a something like 20k addresses, not sure how many domains offhand, but a lot): https://www.postgresql.org/message-id/162786859325.25751.2226078786729473978%40wrigleys.postgresql.org We do also take quite a bit of care on our regular mailing lists to ensure that we don’t break DKIM, which has generally been successful when it comes to being allowed even when restrictive policies are in place, but that isn’t relevant to whatever is going on here. Thanks, Stephen > ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] free.fr / tdsnet.com / zeelandnet.nl bounces
Greetings, We have quite a few folks with @free.fr addresses, and a few with the other domains listed in $subject, on the @postgresql.org mailing lists and recently we've started getting bounces back for some of the emails we send out, claiming they're spam (which they certainly aren't). If this continues, we're going to have to unsubscribe them all, but figured I'd reach out here first to see if there's any free.fr admins (or those for the other domains, though we have just a few of those) paying attention who could help us figure out why these emails are being classified as spam and help us work to a resolution. These emails from coming from 217.196.149.56 / 2a02:16a8:dc51:0:0:0:0:56, SPF matches, DKIM signed, passes DMARC, etc. Our best guess is that the ones being marked as spam have too many URLs or some other silly measure that's tripping up a poorly designed spam filter. Thanks, Stephen (One of the postgresql.org admins) signature.asc Description: PGP signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Spamcop
Greetings, Yes, we also saw that all lookups against the blocklist resulted in blocks. As I recall, the issue was that everything was returning the same IP for the 'domain parked due to being expired' website. We check all of our hosts (even ones that don't send email) and they all reported being listed. This was using the 'check_bl' nagios plugin and running it by hand against domains which I know wouldn't return anything resulted in 'Not black-listed', so I don't think it was a bad blocklist lookup implementation. One of the other admins said that it looked like the registar implemented a *.spamcop.net record that returned the same IP for anything asked of it, which is why the entire internet was suddently registering as 'blocked'. Thanks, Stephen * Don Owens via mailop (mailop@mailop.org) wrote: > I've received a report from someone that said that all IP lookups against the > SpamCop blocklist resulted in blocks during this time. Did anyone else have > the same observation? I'm trying to figure out if this person has a bad > blocklist lookup implementation (saying an IP is in the list, as opposed to > returning an error, when the blocklist DNS is unavailable), or if it was > something larger. > > ./don > > > > On Jan 31, 2021, at 09:01, Don Owens wrote: > > > > We have the domain back now, but we have to wait for propagation delays. If > > you query the name servers they Arne mentioned, that should give you the > > right IPs. > > > > Sorry for the trouble, folks. Now I have to go see who needs flogging. > > > > ./don > > > > > > > >> On Jan 31, 2021, at 08:36, Arne Jensen via mailop > >> wrote: > >> > >> > >>> Den 31-01-2021 kl. 16:56 skrev Andreas Schamanek via mailop: > >>> > >>> Could someone provide the old but apparently still valid IP addresses > >>> so that we can configure DNS forwarding locally instead of disabling > >>> the DNSBL? > >>> > >> Domain was updated ~21 minutes ago on 2021-01-31T16:04:06Z, now saying: > >> > >> Name Server: NS1-109.AKAM.NET > >> Name Server: NS1-11.AKAM.NET > >> Name Server: NS1-73.AKAM.NET > >> Name Server: NS1-90.AKAM.NET > >> Name Server: NS1-93.AKAM.NET > >> Name Server: USE1.AKAM.NET > >> > >> -- > >> Med venlig hilsen / Kind regards, > >> Arne Jensen > >> > >> ___ > >> mailop mailing list > >> mailop@mailop.org > >> https://list.mailop.org/listinfo/mailop > > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop signature.asc Description: PGP signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Looking for possible mailing list hosting
Greetings, * Dave Shevett via mailop (mailop@mailop.org) wrote: > Hey folks, maybe ya'll can help us out. We've been running mailman on > a set of linodes for... er, a long time. We're having problems > dealing with DKIM stuff, particularly with google. Yeah, we decided against mailman due to that issue and a few others. > Does anyone know of a hosting company that uses mailman (or something > roughly equivalent) and doesn't cost an arm and a leg? We're a social > community that uses the mailing list for internal dicusssions - this > isn't customer facing stuff. > > We're looking at groups.io as well - any other suggestions? Certainly understand wanting to get away from running your own thing, but if you're open to considering an alternative bit of software that cares a good bit about making sure to not break DKIM, et al, you might check out pglister which is what postgresql.org uses and which we maintain. We're not a huge operation but not small either (few hundred thousand emails a day outbound). Might be a few rough spots around getting it to work outside of our infra, but that was part of the original design and hopefully wouldn't take too much and we'd appreciate it being more accessible to others to use (and contribute back to). https://gitlab.com/pglister/pglister Thanks, Stephen signature.asc Description: PGP signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] o2.pl / wp.pl
Greetings, Does anyone have a contact for o2.pl or wp.pl..? We are getting a fair bit of our mailing list email bounced by them and are trying to reach out to someone to clear that up, otherwise we're going to have to unsubscribe something like 100 folks. What's being bounced doesn't seem to have any consistency to it, all outbound mail passes SPF/DKIM and comes from a pretty well trusted IP (Medium Trust) that's been around for quite a while and we successfully deliver to lots of folks without issue. Thanks, Stephen signature.asc Description: PGP signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Anyone else noticing comcast.net backing up....
Greetings, * Eric Tykwinski via mailop (mailop@mailop.org) wrote: > Seems like they are having some smtp issues, lots of timeouts on a few > servers I've checked. Yeah, seeing the same. Looks like it's been going on for about 4 hours now. Thanks, Stephen signature.asc Description: PGP signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Extreme multiple posting (was Re: OVH Bulk Mailer? Anyone know this one?)
Greetings, * Ángel via mailop (mailop@mailop.org) wrote: > On 2020-08-07 at 20:24 +0200, Renaud Allard via mailop wrote: > > On 05/08/2020 20:16, Large Hadron Collider via mailop wrote: > > > you know, Mr Allard, it appears that you sent this message to the list at > > > least 5 times... > > > > Actually, I only sent it once. From my logs, it was delivered on the 5th > > once. It might be some processing problem at mailop because I only > > received it today (once) like multiple other mails from mailop. > > It's fun that we got multiple copies on *different* messages. In my case, > it was on the ones from Umut Alemdar > (am6pr08mb5158c5d0677d418f254e7a16db...@am6pr08mb5158.eurprd08.prod.outlook.com), > Lily Crowley > (cabpqdsmwn_r9q9mmzkuizfgfmnh0fcbdvtigtc8codcm6lz...@mail.gmail.com), > Stephen Frost (20200805132959.gd12...@tamriel.snowman.net), Hans-Martin > Mosner (173bec91138.2771.03b21a1406dc7ce0e2b3b53a52883...@heeg.de) and > Otto J. Makela mails (b05c8075-fbf9-1c87-3322-2b5eb7a94...@iki.fi). I > received 38 copies of each (except Stephen's which were 39). That's certainly interesting- my logs pretty clearly show that 20200805132959.gd12...@tamriel.snowman.net was delivered just once, and on the first try to mx0.nosignal.org: Aug 5 09:29:59 tamriel postfix/pickup[4936]: 8EDAD5F79F: uid=1000 from= Aug 5 09:29:59 tamriel postfix/cleanup[5038]: 8EDAD5F79F: message-id=<20200805132959.gd12...@tamriel.snowman.net> Aug 5 09:29:59 tamriel postfix/qmgr[2185]: 8EDAD5F79F: from=, size=1936, nrcpt=1 (queue active) Aug 5 09:30:22 tamriel postfix/smtp[5086]: 8EDAD5F79F: to=, relay=mx0.nosignal.org[2001:41c8:51:83:feff:ff:fe00:a0b]:25, delay=23, delays=0.08/0.01/0.82/22, dsn=2.0.0, status=sent (250 OK id=1k3JV7-00069W-F7) I then received it, again, just once: Aug 5 09:36:17 tamriel postfix/smtpd[3354]: connect from chilli.nosignal.org[2001:41c8:51:83:feff:ff:fe00:a0b] Aug 5 09:36:18 tamriel postfix/smtpd[3354]: 4FD4A5F7A0: client=chilli.nosignal.org[2001:41c8:51:83:feff:ff:fe00:a0b] Aug 5 09:36:19 tamriel postfix/cleanup[5816]: 4FD4A5F7A0: message-id=<20200805132959.gd12...@tamriel.snowman.net> Aug 5 09:36:22 tamriel postfix/local[5817]: 4FD4A5F7A0: to=, relay=local, delay=4.4, delays=2.9/0/0/1.5, dsn=2.0.0, status=sent (delivered to command: procmail -a "$EXTENSION") Aug 5 09:36:22 tamriel postfix/qmgr[2185]: 4FD4A5F7A0: removed However, I've seen similar symptoms to what's being described here previously, but in the case I saw it before where there were multiple deliveries of the same mail, the issue was that the receiving side would accept the mail but the sending side got back some kind of error that indicated there was a failure, and therefore it kept the message in the queue and retried. This is particularly possible if there's tight timeouts involved- if chilli.nosignal.org had a 10s timeout on sending and the receiving side sat and contemplated the message (after having received it) for >10s before actually acknowleding the message as accepted, that's exactly the behavior you'd see. Might be interesting to see if you can spot that in your logs as having, perhaps, happened, where there was a long delay between the connection from chilli.nosignal.org and the message being accepted and if there was any indication in the logs that there was a failure to acknowledge back to chilli.nosignal.org that the message had been received. Thanks, Stephen signature.asc Description: PGP signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Challenges delivering to cox.net
Greetings, * Alessandro Vesely via mailop (mailop@mailop.org) wrote: > On 2020-08-05 11:09 p.m., John Levine via mailop wrote: > >In article <20200805132959.gd12...@tamriel.snowman.net> you write: > >> > >>I'm part of the group that runs the postgresql.org mailing lists and > >>we've been having some challenges getting email delivered to cox.net due > >>to their... rather aggressive max-connections blocking. Their unblock > >>request support was less than helpful. > >> > >>Anyone on here who could perhaps help out, or at least commiserate? > > > >I've had similar problems with Comcast, and dealt with it by twiddling > >the MTA behind the mailing list to rate limit the number of > >connections per destination. In my experience it doesn't slow the mail > >down much and makes those problems go away. > > Not with Cox. I set MAXHOST=1, which seems to effectively limit outgoing > sessions per MX.[*] However, whenever I happen to send them mail I keep > getting those 421 replies and bogus "too many sessions". > > Sometimes it takes several hours to send a few dozens messages. I'll share that, thanks to this list, the issue we were having with Cox ended up being successfully resolved. I encourage others having challenges to provide their info here and hopefully they'll have a similar response and be able to work through it. Thanks, Stephen signature.asc Description: PGP signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
[mailop] Challenges delivering to cox.net
Greetings, I'm part of the group that runs the postgresql.org mailing lists and we've been having some challenges getting email delivered to cox.net due to their... rather aggressive max-connections blocking. Their unblock request support was less than helpful. Anyone on here who could perhaps help out, or at least commiserate? Thanks, Stephen signature.asc Description: PGP signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
