Re: validating from
On Sat, 2 Jun 2012, Matt Simerson wrote: 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? For starters, you would penalise this message, and perhaps not see it. If the To header exists, shouldn't that also be validated against RCPT TO? Also wouldn't work well for mailing list messages.
Re: validating from
On Jun 4, 2012, at 9:26 AM, Charlie Brady wrote: On Sat, 2 Jun 2012, Matt Simerson wrote: 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? For starters, you would penalise this message, and perhaps not see it. If the To header exists, shouldn't that also be validated against RCPT TO? Also wouldn't work well for mailing list messages. 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
Re: validating from
On Mon, 4 Jun 2012, Matt Simerson wrote: On Jun 4, 2012, at 9:26 AM, Charlie Brady wrote: On Sat, 2 Jun 2012, Matt Simerson wrote: Is it a good idea to validate that the MAIL FROM address is the same as the From: header in the message? ... Also wouldn't work well for mailing list messages. 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. You mean Mailing-List. Other mailing lists have different headers - e.g. LKML has X-Mailing-List. Others may have none. I'd expect that most lists would similarly mark up the message. Is similarly good enough? Are you going to enumerate all the variations? 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. Maybe. 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. Consult RFCs before you mess with any headers. Has this been done before? Should it be? Matt
Re: validating from
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? 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
Re: validating from
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. 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. 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. This might still be too strict, but it would probably go over better. At least there would be recourse if there are FP's If the To header exists, shouldn't that also be validated against RCPT TO? One would think.. but again I'd expect FP's to happen because of legitimate senders doing strange, interesting, and foolish things. -Jared
