Posts Tagged ‘btinternet’

|

BT/Yahoo You Have This slightly better!

Permanent Link posted December 20th, 2007

It looks like after approximately 3 weeks BT/Yahoo have actually worked out what greylisting is meant to be and have applied this to their servers.

Dec 20 06:58:18 cobalt qmail: 1198133898.559094 starting delivery 1113: msg 7375264 to remote ahiddenemail@btinternet.com

Dec 20 06:58:19 cobalt qmail: 1198133899.434814 delivery 1113: deferral:
Sorry,_I_wasn’t_able_to_establish_an_SMTP_connection._(#4.4.1)/ (this message varies from the typical deferred to this)

Dec 20 07:04:58 cobalt qmail: 1198134298.251333 starting delivery 1139: msg 7375264 to remote ahiddenemail@btinternet.com

Dec 20 07:04:58 cobalt qmail: 1198134298.621727 delivery 1139: success:
195.50.106.135_accepted_message./Remote_host_said:_250_ok_dirdel/

Oh Look! One deferral and then it’s accepted and it remembers too although it looks like individual mail servers have to greylist individually.

So, 3 weeks later, approximately 25 forms filled in, 6 stock answers, 1 request for more information (unanswered) and several requests to see if I wanted help to set up Outlook Express and we’re finally there. Although I feel that this was always going to happen once they realised what was happening, and any fix is not the result of our endless paper pushing.

Tags: , ,
Posted in New Business | 2 Comments »

BT/Yahoo You Have This Wrong!

Permanent Link posted December 1st, 2007

Over the last week BTInternet (now of course merged with Yahoo) have systematically been making noticeable changes to their email systems. It seems they have waged a new war on spam, which is of course commendable but they have got it totally totally wrong. They are blocking emails from legitimate users through misuse of a process called Greylisting.

Greylisting done correctly, rejects email on the first send attempt with a usually helpful message for admins - It is not bounced to the sender. Ours for example says

greylisting_in_effect_temporary_local_problem_451

This informs the sending server to resend after a set period of time after which the IP is added to a pseudo-whitelist and further email is allowed through unhindered. The premise of this working is that zombie PCs do not have ‘normal’ SMTP servers and thus do not conform to SMTP RFC, more specifically the part referring to ‘SMTP being an unreliable protocol (which it is) and thus, will resend email over a period of time’. Zombie PCs do not resend - yet.

Thus greylisting is a nice part of a layered anti-spam solution because it filters out the most stupid, and thus common spammers. It would be trivial to code around for a spammer if greylisting became mainstream. They would simply but a retry in after 15 minutes.

Now, BT/Yahoo. We first noticed this issue from customers emailing in (because of course, greylisting systems don’t send bounces) that emails were not getting through. We later discover that over the course of several days this has been applied to different servers that we operate, on 4 different subnets, on 2 different continents. This appears then to be a general change on BT/Yahoo’s network. Unfortunately, their system does not appear to be foolproof, or working correctly, or something. It appears that after going through greylisting:

- the sender is not whitelisted

- the email is simply not sent

- the admin is not informed greylisting has even been in effect

From tests we have conducted the sheer amount of time this is taking means that initial emails are not getting through for up to 1 hour. Would you want to wait 1 hour for an email?

Here is an example (I’ve stripped out the chaff):

from

@400000004751317213ed6ae4 starting delivery 212: msg 67612 to remote hiddenemailaddress@yahoo.co.uk
delivery 212: deferral:
Connected_to_195.50.106.7_but_greeting_failed./Remote_host_said:_421_Message_from_(our_smtp_IP)_temporarily_deferred_-_4.16.50._Please_refer_to_http://help.yahoo.com/help/us/mail/defer/defer-06.html/

@400000004751330327262204 starting delivery 213: msg 67612 to remote hiddenemailaddres@yahoo.co.uk

@40000000475133070037cb34 delivery 213: deferral:
195.50.106.7_failed_after_I_sent_the_message./Remote_host_said:_451_Message_temporarily_deferred_-_[160]/

@40000000475137b330f4092c starting delivery 214: msg 67612 to remote hiddenemailaddres@yahoo.co.uk

@40000000475137b40a85811c delivery 214: deferral:
195.50.106.7_failed_after_I_sent_the_message./Remote_host_said:_451_Message_temporarily_deferred_-_[160]/

@40000000475137b40a85bf9c status: local 0/10 remote 0/255

Ok, so they give us a link which redirects to here. This implies that emails will be accepted if resent and the server conforms to RFC guidelines (which they are) and not on blacklists etc.. (which they’re not). Trouble is, 75% of emails never get to this stage. I’ve had a test email sat in the outgoing queue of a 10-email-a-day standard email server with all-conforming reverse DNS, SPF setups, for nearly 50 minutes now. No successfully delivered message.

So here we are. Can’t speak to anyone at BT/Yahoo. Their support lines panic when we start mentioning SMTP and that we don’t want help setting up Outlook Express (??). postmaster@yahoo.com works for complaints but asked us strange questions that again made no sense relating to how we are an individual user having problems sending email to a single @yahoo.com address. postmaster@btinternet.com simply did not give us a reply, even an automated one. The forms at yahoo from the above links have been filled out ad infinitum with no reply.

As I’ve said. Greylisting and deferral of email is right in its place. BT/Yahoo’s implementation of this and their own rules however is not. All they have done is put a method in place which will be circumvented by the people they are trying to block with minimal fuss, whilst at the same time creating confusion and frustration for both their own clients and server admins. Well done.

Tags: , , , ,
Posted in Web Hosting | 1 Comment »