Mail delays/failures and uncooperative admins

[ronanian]

We've been getting some reports of email failures where someone would try to send to us, and a few hours later it bounces with a failure. It happens with people at different organizations, but all those organizations happen to use the same hosted email service, onechoice.net.

 

What's actually happening is that onechoice.net is trying to send to us, getting a transient/temporary failure to connect, and retrying a single time after two hours. This is in violation of RFC 2821, which says ""Retries continue until the message is transmitted or the sender gives up; the give-up time generally needs to be at least 4-5 days." It's also insane...I've never seen a SMTP send queue that gives up after less than 3 days.

 

I'm not concerned about the connection failures; we get hammered by spam DoS attacks and there's not much I can do about it. We have a project for a new mail server that will be more robust, waiting for funding that's definitely going to come in but we don't know when.

 

So, I figured I'd call onechoice.net and ask them why their SMTP server gives up after two hours. I did a whois to get their technical contact number. When I called it, I got a scam (described at http://edumacation.com/TelSeven ). Finally I gave up and called the customer support number on their website. Of course, since we're not a customer, they can't put in a ticket for us, but the guy was nice and tried asking the networking people about it.

 

They said that it was "by design" and that they couldn't change it. Well, the RFC has something to say about that, too: "The parameters to the retry algorithm MUST be configurable."

 

It's causing difficulty for the users, it's making me look bad, and it's a crazy way to setup a server. What can I do?

 

Here's a portion of what the failure looks like, in case you don't know what I mean. Look at the time the DSN was sent, and look at the time the original message was sent...

 

From: [email protected]

Date: January 31, 2008 11:54:00 AM EST

To: [email protected]

Subject: failure notice

 

Hi. This is the qmail-send program at roc-smtp4-sun.choiceone.net.

I'm afraid I wasn't able to deliver your message to the following addresses.

This is a permanent error; I've given up. Sorry it didn't work out.

 

:

Sorry, I wasn't able to establish an SMTP connection. (#4.4.1)

I'm not going to try again; this message has been in the queue too long.

 

--- Below this line is a copy of the message.

Return-Path:

[snipped: Received lines and some other stuff]

From: "[email protected]"

Subject: Re: Dennis O'Hara Talks

Date: Thu, 31 Jan 2008 10:07:14 -0500

[Geoff]

Black hole them, submit them to rfc-ignorant.org. If more users come your way telling you they can't get mail. Tell them to use a mail host with a clue.

[ronanian]

Nice! I've never heard of rfc-ignorant.org.

[ronanian]

Oh, drat! Either I misdialed twice yesterday, or they've cleaned up their phone number issue. I tried dialing that number again and actually got through.

 

In the meantime, it looks like rfc-ignorant.org doesn't have a place to report the RFC 2821 violation.

[Geoff]

I'm sure they'll start one if you ask.

[PiqueABoo]

This is in violation of RFC 2821

 

Maybe, but I'm not so sure and last time I looked that was still a proposed standard for SMTP on the Internet. RFCs are not Internet standards, but most Internet standards are pointers to one or more RFCs.

 

Pragmatically RFC2821 is the de-facto standard, will be the fully fledged Internet standard for SMTP and I would be miffed by your scenario, but all we can really say is that their MTA behaviour is rather annoying and sometimes prevents mail delivery.

 

Equally pragmatically, running serious MTAs in the face of things like current Spam levels has forced people to ignore occasional "rules" in RFCs and that is perfectly understandable.

 

Then there's an RFC out there which is also an Internet standard which says I ought to be able to ping any host connected to the Internet and get a response, which I obviously can't because people often prevent that. If you wriggle a bit you can find an unintended loophole in the wording, but that's obviously going against the original author's intent, albeit for yet more understandable reasons.

Edited February 1, 2008 by PiqueABoo