Is it a good idea to validate that the MAIL FROM address is the same as the From: header in the message?

What exceptions need to be made, if any?

What problems might I encounter if I were to do this?

I ask because I have a client who is currently getting spammed viciously by spammers who use one address in MAIL FROM (to pass SPF tests) and they use the senders email address in the From: header so they can get whitelist scoring by SpamAssassin. It's pretty clever.

I'm contemplating writing a plugin that would validate that they are the same. Pointers to RFCs, previous implementations, similar ideas, and further reading are welcome.

Another way to solve part of this problem is that if MAIL FROM contains a local domain, reject it unless relay_client is set and the local user exists.

If the To header exists, shouldn't that also be validated against RCPT TO?

Matt

`````````````````````````````````````````````````````````````````````````
  Matt Simerson                   http://matt.simerson.net/
  Systems Engineer            http://www.tnpi.net/

  Mail::Toaster  - http://mail-toaster.org/
  NicTool          - http://www.nictool.com/
`````````````````````````````````````````````````````````````````````````

Having perused a lot of spam and non-spam, I would generally expect you to
have problems if you were very strict about this.  Our solution to
"self-whitelisting" issues is that our whitelisting plugin ignores any
whitelist with the recipient's own domain in it.  You could perhaps do the
same thing with some sanity checks after the fact (or before the fact, if
you have a UI through which people enter SA whitelists).  We got tired of
tip-toeing around SA, though, so we simply changed our UI to save
whitelist in our own native table rather than SA, and wrote our own
plugins.

This might still be too strict, but it would probably go over better.  At
least there would be recourse if there are FP's

One would think.. but again I'd expect FP's to happen because of
legitimate senders doing strange, interesting, and foolish things.

-Jared

For starters, you would penalise this message, and perhaps not see it.

Also wouldn't work well for mailing list messages.

On Jun 4, 2012, at 9:26 AM, Charlie Brady wrote:

Aye, good one.

Exception #1:  mailing lists

I should be able to detect mailing lists though. For example, this list has a Mail-List header. I'd expect that most lists would similarly mark up the message.

I don't anticipate using From validation as a condition for rejection, but if you aren't a mailing list, and you aren't ( OTHER EXCEPTIONS HERE), then I might want to ding your karma for having a forged From header.

In addition to whatever value it might have for Bayesian filters, it may be useful to always add an X-From: header, so that diagnosing email problems like my client with the forged From: header would be easier. I had to grep through his server logs to see how the spammer bypassed the SPF and SA tests. (SA only sees From: and SPF only uses MAIL FROM).

I wonder if X-Rcpt-To should be similarly added.

Has this been done before?  Should it be?

Matt

You mean Mailing-List. Other mailing lists have different headers -
e.g. LKML has X-Mailing-List. Others may have none.

Is "similarly" good enough? Are you going to enumerate all the variations?

Maybe.

Consult RFCs before you mess with any headers.

Our forked stuff adds X-Envelope-Recipient and X-Envelope-Sender headers
to messages, and we've found them useful.  But note that we inject a
separate message into the queue for each recipient, which means that every
message has only one X-Envelope-Recipient header which should already be
known in some way to the real recipient of the message.  If you use the
normal method of injecting a single message into the queue for multiple
recipients, and therefore include multiple X-Envelope-Recipient headers,
then you're going to wind up violating the intentions of a sender who
BCC'd multiple recipients to avoid letting all the recipients in on each
others' email addresses.

-Jared