Bill, I'm going to be fairly critical, so please recognize that I am being critical of Danisch's proposal, not your message. :-)
I've looked at it Danisch's proposal before, and posted information about it. He still has a problem with BIND (see: http://www.danisch.de/software/rmx/). You can track his updates at http://www.danisch.de/work/security/antispam.html. But although I was initially hopeful, after I had read through it I realize that his proposal is both seriously and fatally flawed, without major changes to existing mail RFCs in order to make it even remotely viable. One problem with his proposal is 8.3. Without requiring 8.2, his proposal amounts to little more than additional tracking information by convention in the Received header, because the rest of the proposal goes by the wayside in the case of 8.3. Another flaw in his proposal is section 10.1.7, which objects to RFC mandated <> address used to indicate, essentially, that no DSN should be sent for the message. He recognizes this as a problem, and concludes that the SMTP RFC needs to be changed. None of the above really matter, though, because of another flaw in his proposal. He is validating the MAIL FROM (see section 4), which is not required to be the same as the Sender or From fields. Not only is it not required, but it is necessary that it not be the same. Sender:, From:, To:, Reply-To: and the reverse-path all have different roles in the mail system. All that I need to do as a spammer is use a correct reverse-path along with a spoofed From: or Sender:, and I completely bypass his schema. It is just that easy to break. You can see this by looking at his sample sendmail filter. This is a fatal flaw that renders the entire proposal moot. If I can do this: telnet parducci.net smtp helo parducci1.parducci.net mail from: <[EMAIL PROTECTED]> rcpt to: <[EMAIL PROTECTED]> data Sender: Arabic News Service <[EMAIL PROTECTED]> From: Osama <[EMAIL PROTECTED]>, Saddam <[EMAIL PROTECTED]> Subject: Greetings ... Then the real problem would be that parducci.net is an Open Relay. I've already bypassed the RMX mechanism. So it is more important to close Open Relays and to block DHCP pools, either outbound at the ISP's router, or incoming at each MTA (except for defined exceptions). Now your MUA is only able to contact the authorized MTA(s), or your own over some sort of secure protocol. No more spam from DHCP pools. These are all things that we can do NOW with existing RFCs and technology. My server blocks relaying except from specific addresses, and treats all DHCP direct mail as spam (with one DNS controlled exception). I check my mail over a compressed SSH tunnel, and can send e-mail that way, although I tend to use my ISP's SMTP server and bandwidth. The ASRG Working Group also seems to consider the RMX proposal "weak" and "fundamentally flawed" from what I have read on their mailing list. --- Noel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
