Summary from 25 July: three causes of deferral sending to mx.bt.lon5.cpcloud.co.uk (btopenworld.com etc) 1) "421 Too many messages (1.5.6.1)" (after MAIL FROM) 2) server dropping connection (while sending RCPT TO) 3) "451 System policy engine error" (after end of DATA section)
On Wed, 09 Sep 2015 20:58:21 +1000, Bron Gondwana <br...@fastmail.fm> wrote: > Did you ever hear back from them? I've had a > little bit of response, but I still have a queue full of emails which > aren't moving. It kinda sucks for my customers to have their emails > hanging for days. I spoke to OpenWave support (+800 22288800), who decoded 1.5.6.1 as too many non-SPF-authenticated (?) connection attempts, and referred me to fairly generic advice at http://bt.custhelp.com/app/answers/detail/a_id/47055/~/bt-mail---best-practices-for-postmasters-and-senders-of-bulk-mail Plus I got a kind response from Steve postmas...@btinternet.com, suggesting any SPF record (eg softfail or neutral) would reduce number of SPF fails, or delays. So brownie points from me for professionalism, responsiveness and a consistent answer. However, I'm less convinced that apparently random greylisting based on SPF results is a good substitute for general IP reputations and content scanning, as it can build up delivery delays as you mention. A huge amount of spam passes SPF, while a huge amount of ham fails SPF. And we don't want to add SPF on behalf of client organisations who may for example use some ESP we don't know about. Plus the policy isn't publicly documented or very clear: converting SPF none results into passes *doesn't* reduce fails. There will be SPF fails from this IP address because it receives a lot of mail to users' mailboxes and mail that they choose to forward on to an address at say @btinternet.com, and forwarding generally breaks SPF. They may just need to take other factors into account when greylisting/throttling. Anyway, I'm still seeing some 421s with 1.5.6.1 and 1.5.6.2 (and a couple of 1.2.6.1), but not in the same volume as before. > https://community.bt.com/t5/Email/BT-email-accounts-rejecting-emails-we-send-on-behalf-of-our/m-p/1531608#M37145 > Looks like it's been ongoing for months. *sigh* Since BT moved contract from Yahoo, in fact. At the moment, problem 3) appears to be resolved. As for problem 2): On Mon, 07 Sep 2015 22:22:26 +1000 Bron Gondwana <br...@fastmail.fm> wrote: > > We're getting connection dropped after RCPT TO for customers trying > to email to BTInternet. > > (delivery temporarily suspended: lost connection with mx.bt.lon5.cpcloud.co.uk[65.20.0.49] while sending RCPT TO) I *didn't* see this on Monday. However I have seen periods of timeouts on 27 August, although some messages were getting accepted at the same time. So still not sure if it is a policy disconnect against RFCs or capacity problem. CK _______________________________________________ mailop mailing list mailop@mailop.org http://chilli.nosignal.org/mailman/listinfo/mailop
