Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

This is kind of a bizarre situation, but here goes: a third-party exim mail server I'm dealing with is seemingly rejecting all messages coming from any e-mail address that starts with "notes".

So notes@foo.com, notes@apple.ca, notes@anything gets rejected when issuing the MAIL FROM SMTP command. Pseudo-transcript:

> telnet bar.com 25
HELO foo.com
250 OK
MAIL FROM: <notes@foo.com>
500 unrecognized command

Every other address works just fine, but any address to a "notes" account returns an unrecognized command. I searched the exim spec, and couldn't find any reserved addresses or anything to do with "notes", so it seems like either this third-party server is misconfigured somehow, or there's some kind of bizarre bug in the version of exim he's using. Or would some spam filters have this sort of behaviour?

Any thoughts?

share|improve this question

2 Answers 2

I think someone may have been silly enough to put in some broken rule to reject email from notes@*. Maybe with the flawed idea it could prevent some spam. I would say grep for "notes" in the exim configuration directory and see what hits you get.

From experience I know there are few or no configuration files in exim that contain the string "notes" by default, so anything that turns up should lead you in the right direction. Remove or comment out any suspect entries you find, reload exim and see if that fixes it.

If there is a proxying spam filter in between such as ASSP you may need to scrutinise that configuration as well.

Update: To answer a comment about quarantining.

Quarantining is only helpful for a limited amount of spam you are not sure about, even then the human factor comes in the way. People will quickly get annoyed and ignore the quarantine thing right away.

Normally you block spam at an early stage of the smtp interchange. It will be grey listed, or the connection is denied due to an IP block list, there is no valid helo, or no valid reverse dns. At this stage no email body has yet been transferred and as such there has been very little traffic. These are cheap and very effective ways to block 95%+ of all spam with very little chance of false positives.

If the spam passes these checks you have less precise and more resource intensive scans such as bayesian scanning and virus scanning. If an email does not pass that scan you block it and you could consider to quarantine the emails that have the lowest score (i.e. it's looking a lot like a legit email).

If you would quarantine all emails that would be blocked the user gets information overload and your system has to handle all that extra traffic, including increased disk usage. The user will NOT sift through thousands of spam to find one legitimate email. So your user will still miss out on "that important email".

As far as I know big email providers work in a similar way, it's common practice.

share|improve this answer
    
Thanks. It's not my mail setup, so I'll have to try and coach them through it, but that's a good place to start at least. I'd be surprised if the spam filtering happened at this level though. Seems more likely that it would simply accept the spam e-mails and quarantine them. –  naasking May 15 '12 at 2:25
    
Accepting spam and quarantining is bad practice for the most part, but I digress. Search the exim configuration and I am pretty sure you will find the culprit. You may also want to check files exim reads from other locations (such as /etc/aliases) –  aseq May 15 '12 at 6:56
    
As an aside, how could quarantining be bad practice? It looks like standard practice to me, not to mention spam filters always have false positives. –  naasking May 15 '12 at 14:29
    
That's a long story, see my answer :-) –  aseq May 15 '12 at 19:53

I suspect that this is the result of an incorrect rule somewhere in your Exim configs. Thankfully Exim provides some fantastic debugging functionality which allows you to simulate an SMTP session while viewing the rules that Exim evaluates on a line-by-line basis. This should quickly let you narrow down the particular rule that is causing trouble.

From the console, run Exim using the -bh argument followed by an IP address from which you would like to simulate the SMTP connection. For example, if you wanted to simulate a remote server with IP address 196.236.151.141 connecting to your mailserver, you would run:

exim -bh 196.236.151.141

You will then enter a telnet-like simulation console where you can input standard SMTP commands while viewing the result of each rule that Exim processes.

Since this is a simulated SMTP session, nothing will ever be sent out or committed to disk, which makes it a great playground for testing your configs and finding out exactly where and why things went wrong.

share|improve this answer
    
Unfortunately, this is a third-party server on a big host that I'm trying to communicate with. I don't have any control over their configs, but it's a little bizarre that such an e-mail address would return "unrecognized command" instead of an "invalid address" or something along those lines. It's just bizarre all around. –  naasking May 24 '12 at 15:56
    
If it's a third-party service provider, it should be well within your rights to request that they solve this issue. Definitely sounds like a borked Exim config. –  Richard Keller May 28 '12 at 21:52

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.