At 9:25 AM +0200 2003/10/15, Stephane Bortzmeyer wrote:

...

http://www.ietf.org/internet-drafts/draft-danisch-dns-rr-smtp-03.txt

Bad idea, like every method that prevents me from using "From: bortzmeyer@nic.fr" (work address) when I'm at home and connected via my IAP Nerim.

I agree. The IETF/IRTF Anti-Spam Working Group is reviewing a number of similar proposals of this nature (including this one), and I am pretty strongly opposed to all of them, for similar reasons. Too many people support this concept to seriously hope that we can get this idea killed in committee before it ever gets into the documents that are generated by the ASRG. However, I can at least hope that enough caveats are added and the known problems it causes are highlighted strongly enough that people are either discouraged from using this sort of technique at all, or they only use it as part of a "whitelist" method. You may want to consider applying to join the ASRG if you feel strongly about this issue. -- Brad Knowles, <brad.knowles@skynet.be> "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(+++)

At 10:03 AM +0200 2003/10/15, Daniel Karrenberg wrote:

However I wish to point out that one's virtual location is quite independent from one's location in the Internet topology.

Indeed. Note that RMX-type proposals also break .forward, /etc/aliases-based mailing lists (probably >80% of all mailing lists in existence are actually just aliases and not done through a proper MLM), and have various other problems.

I have been using tunnels of various description to "be" in many places when I work on my laptop for more than half a decade.

Indeed, but tunnels are not always possible or feasible, and in many cases should not be required. If all you want to do is send a public e-mail message, you should be able to use the local mail relay facilities available to you. In fact, many networks *require* you to use the local mail relay facilities. Of course, some of those are stupid enough to insist that you use a recognized local domain portion for your envelope sender address, which screws you even more. -- Brad Knowles, <brad.knowles@skynet.be> "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(+++)

At 9:50 AM +0100 2003/10/15, leo vegoda wrote:

Isn't this where consumer power and competition law come into play? There are many ISPs and they have different market offerings. You pays your money and takes your choice.

Some people don't *have* a choice. It's certainly hard to have a choice when you are roaming on the iPass or GRiC networks, because you have no clue who your local provider really is.

This works better in countries where there is a competitive market in ISP services, of course.

Indeed. See above. -- Brad Knowles, <brad.knowles@skynet.be> "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(+++)

At 1:41 PM +0200 2003/10/15, hadmut@danisch.de wrote:

I see. Would you mind if I use "From: bortzmeyer@nic.fr" when I am at home?

You can use whatever you want. There's nothing anyone can do to stop you. Moreover, the header "From:" is totally unrelated to the envelope sender address, and there's nothing in your proposal, or any similar proposal, that could successfully keep clever people from doing this sort of stuff anyway. Of course, keep in mind that recent viruses have used legitimate local e-mail addresses to send copies of themselves to people in that person's address book. You certainly shouldn't be able to prevent him from being able to use "From: bortzmeyer@nic.fr" when it's his own machine sending mail from his own MUA, assuming he were vulnerable to this sort of thing. -- Brad Knowles, <brad.knowles@skynet.be> "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(+++)

At 9:27 AM +0200 2003/10/16, hadmut@danisch.de wrote:

- So why is Stephane complaining that these proposals would break his ability to use "From: bortzmeyer@nic.fr" ? 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@skynet.be> "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(+++)

At 3:07 PM +0200 2003/10/16, hadmut@danisch.de 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@skynet.be> "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(+++)