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

[Brad Knowles <]

At 3:07 PM +0200 2003/10/16, hadmut@localhost wrote:

>  I still do not understand your opinion and your argument.
>  If the proposals have nothing to do with the header From line
>  (in fact, they don't), so why are you and Stephane complaining?
	Because we want to use the proper envelope sender address, and 
have the bounces come back to our correct address.  We don't want to 
be forced to use some garbage envelope sender address forced on us by 
the severely misguided which would cause our bounces to go to the 
wrong place, while the header would be unchanged.

>  No. If it doesn't touch the header From line, it doesn't break
>  anything with that. Most mailing lists, all modern mailing list
>  processors I've checked, most forwarding services correctly insert
>  a new sender envelope address and will work with RMX just perfectly.
	Did I say anything about breaking proper mailing lists?  No.  I 
said something about breaking .forward, which does not (and cannot) 
change the envelope sender address.  I said something about breaking 
alias-based mailing lists (which also don't change the envelope 
sender address).  I said something about breaking legitimate 
third-party relay when you are travelling.

	If you're going to argue on some subject, it might be a good idea 
to pay attention to what the other guy is talking about.

>  Wrong. If just Hotmail, AOL and Yahoo would provide RMX records and
>  I'd query them, then I already would get rid of a significat amount
>  of spam. And that's only a four party game.
	Wrong.  Many people legitimately send e-mail from accounts like 
that, with return addresses legitimately within domains like this.

>  And even if I were the only person providing RMX records, it
>  would already help getting rid of wrong delivery failure messages.
	No, there would still be plenty of MTAs that would be 
misconfigured and pay attention to headers like "Errors-to:", and 
you'd be victim of header address spoofing, and the bounces resulting 
from them.

>  DNS cache poisoning is possible, but is found rarely. While I see
>  tens of thousands of Spam per day, I didn't find any case of cache
>  poisoning within the last two years. Do you really believe Spammers
>  would be able to poision the DNS caches of a million receivers?
	Sure.  They can own networks of hundreds of thousands of PCs 
around the world, and use them to DDoS blacklist providers out of 
existence, and do so with impunity.  It doesn't matter if you know 
precisely who they are, where they are, and exactly how they're doing 
it.  You can have video of the act.  It doesn't matter, because no 
one in law enforcement gives a flying flip.

	If they're going to write stealth viruses to take over hundreds 
of thousands or millions of PCs to act as their conduit for spam, or 
to act as reverse proxy cache servers for the hidden websites that 
have the real content, then DNS cache poisoning is a trivially easy 
step for them.

>  Wrong. Nonsense. There's organizational security, e.g. topological
>  authentication, as done by e.g. firewalls. You should be better
>  informed before propagating such claims.
	Weak.  Spoofable.  Easy to work around.  Meaningless.

	These are terms you should become familiar with before you 
participate in discussions on subjects you do not understand.

>  And how should anyone else check this?
	How could anyone else check on this?  The only reasonably 
trustworthy mechanism would involve strong crypto at the core of a 
secure protocol, and even then that could be subverted by easily 
guessed passwords (or sniffed passwords), or any of several other 
attacks.

>  So tell me how my receiving MTA can check this. What cryptographic
>  authentication is he using that could be automatically checked
>  by my machine?
	At the MTA level, you don't.  The best you could do would be to 
authenticate the connection from the sending MTA to your MTA, in much 
the same way SSL certification is done today.

	Oh, wait.  We already have this.  It's called SMTPAUTH.  Then 
there's TLSSMTP.


	If you want to authenticate the message itself, you're dependant 
on the mechanisms that he chooses to put into the message -- PGP, 
S/MIME, whatever.

>  How do you want to deploy such a mechanism to countries where
>  cryptography is not allowed? Do you believe that a billion of
>  internet users will keep the secret keys on their windows machines
>  secret? That's absurd.
	How do you deploy SSL?

>  DNS security is still much better than SMTP security, because there
>  is no SMTP security. Spammers using wrong sender addresses do not have
>  to break any security mechanism by now.
	If you think there is anything remotely resembling DNS security, 
you are not familiar with the subject.

>                                          Breaking DNS is still not
>  trivial, especially not for mass mailings.
	Not at all true.  They're already playing these sorts of games. 
You're just not up-to-date on the techniques they're already using.

>  That's the universal kiddy-argument against everything. Following you
>  would mean to leave it just as it is. The current spam traffic might
>  be suitable to your personal needs, but it isn't to others.
	No, we are working on actually useful proposals to help deal with 
the issue.

>  Aha. AOL has also transported more spam than I will ever see
>  in my life. So what?
	If you haven't seen it, you are not likely to be able to come up 
with ways to successfully combat it.

>  And what does this mean? That every anti-spam solution requires your
>  personal approval?
	No.  There are plenty of people who have useful experience to 
bring to the table.  However, I have seen a lot of dain-bramaged 
ideas in my time, and I am well-suited to pointing out these problems 
wherever I encounter them.

>  Aha. And what does this mean? Do you want to tell me that you have the
>  permission to spam-fight and I don't?
	No.  However, if you're going to try to be part of the solution 
and not just make a bad situation many orders of magnitude worse, you 
need to do your homework.  You need to do research.  You need to talk 
to people who have more experience in this field, and you need to be 
willing to learn from them.

	I have seen no evidence of any of these behaviours on your part.

>  So what are you proposing? Leave it as it is? If you have any
>  better and feasible idea, don't hesitate to tell it. World will be
>  happy to get it.
	I'm working on that within the auspices of the IETF/IRTF 
Anti-Spam Research Group (ASRG).  As the BCP Coordinator, I'm hoping 
that we will soon have some "best practices" that we can recommend 
that sites participate in, and help stem the tide.

>  I see that you don't like RMX. But I don't see what you want to have.
>  A different mechanism? No spam protection at all? What do you want?
	You should see that when the ASRG starts publishing the BCPs.

--
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(+++)