[Dshield] DNS MX record block question
security at admin.fulgan.com
Tue Sep 9 13:37:49 GMT 2003
> --On Sunday, September 07, 2003 11:45 PM +0200 Stephane Grobety
> <security at admin.fulgan.com> wrote:
> > I believe you have failed to see Johannes's point: His first point
> > wasn't about the MACHINE sending the message, it's about the DOMAIN
> > indicated in the "From:" field (the machine should be in the "Received
> > from" header).
> A confusion of terms, perhaps? The From header is not reliable and often
Correct. As such, it shouldn't ever be used for filtering mail since it's so easy to forge (actually, I'm of the opinion that no part of the message header except the subject should be used for filtering mail as it is way too easy to manipulate).
>You want to use the domain specified in the envelope, part of the
> SMTP transaction but not a property of the initiating MTA nor necessarily in
> any header. An MTA forwarding a message is obligated to preserve the envelope
> sender provided by the MTA that gave it the message.
True, but it's also easy to forge that chain by adding false "Received from:" lines.
> > As for the RFCs, they defined a way to send a message that shouldn't
> > be replied to: use blanks "Reply to" and "from" headers (or better, use
> > something in the form of: "Server mail <>").
> That raises an interesting point: What do you do about spam (however defined)
> with an envelope sender of "<>"? On the surface it looks like an automated
> bounce. This looks like an easy hole for spammers to start exploiting to avoid
> this filter.
My personal voice is: nothing. You can't really make the difference between spam and ham based on the From field (as you yourself said).
On a more general base, trying to filter spam based on it's technical headers is not cost effective: not only is it too easy to change for the spammer, but you're in effect denying the "other mail clients" a chance to exist without posing as Outlook Express.
Let me just illustrate this: I'm part of the developpement team of an OSS library of internet component for the Delphi, Kylix and CBuilder environements. Now, since some spammer got their hands on our library and used it, Spamassassin started to filter out all mail that contained our "Library:" header. So, we removed that header (not that it was of any use, anyway). Soon after that, SA started to look for our MIME boundary header. So, what we did was: 1/ randomize that boundary 2/ start a project to have all mail message pose, by default, as OE mail. So, the net result of the SA filtering based on the "technical headers" instead of the content is that a) a lot of legitimate mail was blocked b) we had to developpe a way to prevent SA from doing "its work", indirectly working for the spammers but onyl because we were forced to do so due to the improper filtering. On the overall, a lot of time and energy was lost due to inconsiderate design and features while not improving the !
spam fighting system at all (quite the opposite as SA will now test filters that do not exists any more).
> I'd additionally suggest that a port 25 probe be made to the claimed reply
> server, and that in the event of no reply to the probe, the message be
> tempfailed. Probes should be cached to prevent excessive load on legitimate
> senders. One can use the SMTP VRFY command to submit the claimed reply
> address, although most servers are configured to reject this to avoid
> harvesting. But at least that gives some indication in the sender's log that
> it's not a port scan.
Why would you want to do that ? First, the destination server might not be available at the time of mail transfert (ETRN queues and secondary MXs). Second, it might be undesirable to have a valid reply address (one-way traffic). Third, the reply-to and from used by spammers are, most of the time, forged to be from a major EMail or network provider (yahoo, MSN, hotmail, aol, etc.) so you'll filter very little spam for all the additional work you'll be doing.
More information about the list