About RIPE | Contact  | Search | Sitemap    
Homepage RIPE  
RIPE Community Mail Archives
search  
     
RIPE Navigation Ends
About RIPE Maillists
Maillists Archive
Global Lists
Non Active Lists
RIPE NCC Navigation Ends
Next Section
<<< Chronological >>> Author Index    Subject Index <<< Threads >>>

Re: [dns-wg] DNS RMX records - e-mail sender authorization

  • To:
  • From: Brad Knowles < >
  • Date: Thu, 16 Oct 2003 13:07:56 +0200
  • Cc: Brad Knowles < >
    Stephane Bortzmeyer < >

At 9:27 AM +0200 2003/10/16, hadmut@localhost wrote:

 - So why is Stephane complaining that these proposals would break his
   ability to use "From: bortzmeyer@localhost" ? In fact, none of the
   proposals would stop him from doing so, but since he complained
   about this emotionally, I tried to pick up his argument the same
   way. People should read and understand a draft before attacking it.
I have read the various drafts, and I understand how they work. They all rely on someone designating a set of servers that are allowed to send e-mail from a particular domain or set of domains. Regardless of the implementation mechanism, that act alone breaks .forward, alias-based mailing lists, legitimate third-party relay when you are travelling, etc....

   However, if such a mail turns out to be forged (i.e. it has not
   been written by the sender specified in the From: line) or is
   any kind of fraud, worm, virus,... then it needs to be tracked back
   to where it came from to identify the _sender_ . There is no
   technical way to verify the author, except for cryptographical
   signatures, which are undeployable in a world wide scale.
Right, and nothing you do with an RMX-like proposal is going to make any difference here. The problem is that it doesn't help you until everyone (or most everyone) already does it, and until then it can only hurt.

That is, unless it is only used as a whitelist mechanism, in which case what has it really bought you (and the entire rest of the Internet) to try to force everyone to do this?

   But there is a way to do a light weight verification of the
   sender of the message by checking the authorization. That's what
   RMX and the RMX-like proposals do.
No. That is not at all what they do. That is what they *claim* to do.

With DNS cache poisoning, all that goes out the window. With over 50% of the ccTLD authoritative nameservers being open public caching/recursive nameservers, just how clueful do you honestly think people are going to be? And this is just one of many weaknesses.


If you want to do authentication, you need those cryptographic methods. Nothing short of that is going to help.

   You need to understand the technical, legal and semantical
   difference between sender and author. Otherwise you're lost.
	That is precisely what I would say back to you.

 - Even if he is the owner of his machine, this does not automatically
   mean that his is the owner of this particular domain or address.
He may not own that domain, but he almost certainly owns that address. And he's already got his MUA configured to use the appropriate outbound mail server, including all cryptographic authentication methods required to make the transmission of mail a smooth and invisible process.

   To invent e-mail security, there must be a technical difference
   between those who are authorized to use an address and those who are
   not. This difference must be detectable by receivers. That's how
   security works.
You're not going to invent anything useful using fundamentally flawed ideas using systemically dain-bramaged DNS infrastructure around the world. If you think SMTP security is bad, you haven't begun to look at DNS security.

 - If the virus needs to use a legitimate address, then any
   error messages of virus filter will be sent back to the
   person responsible for that machine, and the machine can
   be fixed or taken offline. This is not possible if the error
   messages are sent to the wrong address.
That's assuming that the mailbox of the sender isn't already full of other bounces. That's assuming that the virus doesn't surreptitiously check the mailbox and delete all bounces, so as to cover it's tracks. That's assuming that the MTAs all along the chain are properly configured and actually issue bounces back to the envelope sender address, as opposed to paying attention to some easily forged header of some sort. That's assuming a whole hell of a lot of other things.

 - I and many other people are currently drowning in error messages
   from relays which received worm messages with my/their domain
   as a sender address. This is a much bigger problem than the
   worms themselves. RMX will stop this imediately.
Something must be done. This is something. Therefore, this must be done.

Riiiiiiiiiiiiiiiiiight. We've heard this before.


As the former Sr. Internet Mail Administrator for AOL, I've probably been responsible for stopping more spam than you will ever see in your life. As one of the authors of some of the earliest anti-spam rulesets that were contributed back to the community, I am probably indirectly responsible for having stopped many, many orders of magnitude more spam than you can ever possibly see in your entire life.

We're all suffering. What we shouldn't do is wave large quantities of weapons of mass destruction around in a crazied attempt to kill all the bugs -- doing so can only lead to our own destruction, and minor annoyance for the bugs.

--
Brad Knowles, <brad.knowles@localhost

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-Benjamin Franklin, Historical Review of Pennsylvania.

GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)




  • Post To The List:
<<< Chronological >>> Author    Subject <<< Threads >>>
 

Next Section
     About RIPE | Site Map | LIR Portal | About the RIPE NCC | Contact | Copyright Statement
RIPE.NET Homepage LIR Portal RIPE Community