Esat introduce greylisting on IOL.IE accounts?

pgargan

Hi,

I've an iol.ie email address which is a carryover from an IOL Gold dialup package, though I'm now on Esat broadband.

Yesterday (Friday June 1st) I noticed that many emails to me seem to be getting delayed. They were arriving with a 'Sent' timestamp that was several hours before the time they were received.

Viewing the Received: headers showed the delay was in the hop from the sender's ISP to Esat's inbound SMTP server. One mail provider could easily be having problems, but several?

Eventually I twigged that it could be an Esat problem, specifically Esat greylisting incoming email. They wouldn't do this without consultation, would they? On the Friday of a bank holiday weekend? :mad: Symptoms as follows:

Fisher:~ paul$ host -tmx iol.ie
iol.ie mail is handled by 10 hub.mail.esat.net.

Fisher:~ paul$ telnet hub.mail.esat.net 25
Trying 193.120.142.92...
Connected to hub.mail.esat.net.
Escape character is '^]'.
220 hub10.mail.esat.net ESMTP Sat, 02 Jun 2007 20:16:56 +0100
HELO test
250 hub10.mail.esat.net Hello test [89.100.154.156]
MAIL FROM: <whatever@example.com>
250 OK
RCPT TO: <whatever@iol.ie>
451-89.100.154.156 is not yet authorized to deliver mail from
451 <whatever@example.com> to <whatever@iol.ie>. Please try later.
QUIT
221 hub10.mail.esat.net closing connection
Connection closed by foreign host.

Googling for "is not yet authorized to deliver mail from" shows it's the greylisting text used by Exim (or an Exim plugin?) Esat are using Exim.

I put all this in an email to the Esat ResidentialSupport address, but I've heard nothing back (maybe their reply has been greylisted?:rolleyes:).

Today, I phoned their tech support number. The tech denied greylisting had been turned on (but...!) yet ultimately noted he wasn't involved with the mail servers in depth. And no, he couldn't transfer me to someone who did deal with mail server queries. He also noted that Esat are within their rights to implement whatever spam filtering they feel is necessary. Well, yes, it's their servers, but still. I asked if it was likely individual customers could opt-out. The tech didn't think so.

Has anyone else noticed this?

Spam is a problem, sure, but I'm not convinced greylisting is the right answer.

- For starters, they haven't whitelisted the SMTP servers of the main Irish ISPs. E.g. I've had delayed mails from UTVinternet.
- I've no idea how they plan to deal with mail server farms whereby a retried email might be sent from a different IP.
- What about one-off emails (password resets, account creation confirmation mails) etc - basically, stuff you want to arrive promptly?
- The retry period is, obviously, at the whim of the sender's ISP. A friend sent me email yesterday from a Gmail address. I've yet to receive it. I've no idea if it's stuck in limbo some place. Other Gmail mails were delivered with a 3+ hours delay.
- What about mailing lists configured to send mails with the envelope set to the sender's address, not the list address? Every message from a previously-unseen poster will be delayed.
- There's no indication of how long the retry window is. If the greylisting config requires the mail to be retried within 12 hours, but a mail server chooses to retry after 18 hours, it'll be perpetually greylisted.

Anyone got any suggestions as to what my next steps should be? Or suggested contact avenues for speaking with someone in Esat who is familiar with their mail server setup? (bearing in mind the sticky requesting individual support staff's details are kept off the boards)?

Thanks in advance,
Paul.

Sponge Bob

exim and spam assasin have been there some time , spam assassin for over a year but spam assassin was inactive for some odd reason , it should have filtered the 10+ score stuff anyway......but didn't.

No spam is coming thru since early today . Maybe they finally turned it on and all the real mail is backing up on the exim relays now. they should realise the implications soon

It may be that your telnet session, from a pc client, was blocked because of the fact thet the client has no spf record in dns . Have you tried from gmail or yahoo ??

JHMEG

My own experience of greylisting was a bad thing. Some MTAs (eg yahoo's) did not retry for up to 8 hours.

watty

Spam generally is now worse than Bubonic Plague etc for anyone running an SMTP.

I've seen mails delayed 2, 7, 12, 20 hrs and more lately on some routes due to volume of spam.

pgargan

Sponge Bob wrote:

exim and spam assasin have been there some time , spam assassin for over a year but spam assassin was inactive for some odd reason , it should have filtered the 10+ score stuff anyway......but didn't.

No spam is coming thru since early today . Maybe they finally turned it on and all the real mail is backing up on the exim relays now. they should realise the implications soon

It doesn't seem like SpamAssassin - the mails are being rejected at the SMTP dialog stage, and from the error text, it seems to be rejecting them solely based on {ip,sender,recipient}, i.e. greylisting.

Sponge Bob wrote:

It may be that your telnet session, from a pc client, was blocked because of the fact thet the client has no spf record in dns . Have you tried from gmail or yahoo ??

I retried from my PC client after an hour or two, using the same {ip,sender,recipient} and it didn't give an error.

pgargan

watty wrote:

Spam generally is now worse than Bubonic Plague etc for anyone running an SMTP.

Tell me about it. I look after the mail servers for a SME. The amount of crap we get is unreal.

I imagine a lot of mail is being sent thru botnets. Surely it's easy for spammers to tweak their bots to retry the mail in the case of a 4xx error, rendering greylisting ineffective?

watty

Yes, Grey listing is too late. It only affects direct spammers, not bots.

rogue-entity

I know I said this before, but, I would hazard a guess that the majority of customers on residential internet connections, do not run their own SMTP server. So, with exceptions made on request, why dont ISPs block outgoing port 25 traffic from residential connections except those to the ISP's own mail server. This kind of policy, if impliamented by the major ISPs worldwide, would eliminate the bot-nets, since most of these rely on compromised windows machines operated by regular residents.

For the laugh, I checked the IP's for the recent crop of SPAM caught by Gmail's filters, they are from residential customers.