Delivery delays with capitalized email recipient

Is this normal?

If someone sends an email to my server with the To name capitalized (e.g. Recipient@) it takes hours for the message to be delivered to the recipient. If the To name is not capitalized (e.g. recipient@) the message is delivered in just moments.

I understand that Directadmin does not enforce the RFC that states email addresses must be case sensitive. This is not a problem. What I am curious to know, is if there is anything that would cause a message with a capitalized To address to be delayed for hours in delivery, and is there anything I can do about it?

I've tried with random capitalization of the left side and of the right side, and of both sides, always from outside the server, to the server hosting my main domain.

None of the emails were delayed.

I'm not sure what you mean about the RFC; can you point to the RFC in question?

Jeff

The latest SMTP RFC 2821 from 2001 says:

“The local-part of a mailbox MUST BE treated as case sensitive. Therefore, SMTP implementations MUST take care to preserve the case of mailbox local-parts. Mailbox domains are not case sensitive. In particular, for some hosts the user "smith" is different from the user "Smith". However, exploiting the case sensitivity of mailbox local-parts impedes interoperability and is discouraged.”

Sounds fairly stupid to me, but there are lots of stupid RFCs out there.

When I think about it, it seems reasonable, though.

Are you saying you'd rather have the mail refused instantly?

Are you using a standard exim.conf file from DirectAdmin? If so, then which version?

Jeff

I think it sounds reasonable to preserve case, but think it is a bad idea in practice. Just about everyone who uses email expects email addresses to be case insensitive.

The only reason I am asking about it is to come up with an reasonable argument to present to my customer asking why my email server is not in compliance with the RFC.

I am using a standard exim.conf from DirectAdmin, version 3.1. I would believe that if it was important for this config file to be updated that CustomBuild would do that during the Exim update process. Your line of questioning leads me to believe that this is not the case. I'll have to ask John about that I guess, as it is near impossible to get a straight answer out of these message boards.

Definitive answers generally come from DirectAdmin Staff, but in the case of exim.conf, I can generally give you a definitive response, since I wrote and maintain the file.

The exim.conf file you're using works, but it's hardly optimized for use by most of us on today's Internet.

The reason that custombuild can't update it is because many of us don't use the standard file. We tweak it for us and for our customers.

In fact, if you read the file's comments you'll see many places where for optimum use you should customize it. For example, to turn on or off blocklisting, SpamAssassin, and ClamAV, all of which are off by default.

The newest SpamBlocker Technology exim.conf file (available as an RC from my site, here, requires customization for installation (and works only with Maildir/Dovecot). I'm hoping that DirectAdmin staff will agree to use it moving into the future, as it's much better at managing spammers, but if so they'll need to either build an automated installation script for it, asking you questions and then writing the file with customizations, or at least documenting what needs to be done to make it work.

Jeff