Why is this even difficult. I have yet to see a firm proposal (ie. an Internet Draft), and once there is one, it is a simple matter of asking an AD to sponsor a BOF to see if there is interest in forming a working group to solve the problem. I remember sitting through several YATP (Yet another Tunnelling Protocol) BOFs years ago, I don't see what the problem is with creating some YASPP BOFs (Yet Another Spam Prevention Protocol). This is the IETF, that is the IETF process... Why are we arguing here about killing it without having a firm proposal, and a BOF chartered to form a WG to go solve the problem. Any more breath we waste now doesn't help anybody. My challenge - Go forth - publish your protocol in ID form, contact the correct APP (probably) area AD and get a BOF in Minneapolis - Convince the IETF in general there that a WG should be chartered to solve the problem. Go and solve the problem Bill On Tue, Sep 09, 2003 at 01:41:33PM -0400, Dean Anderson wrote: > My apologies for this message. This discussion is winding down. Iljitsch > makes some interesting points, to which I have tried to respond > thoughtfully. > > --Dean > > On Tue, 9 Sep 2003, Iljitsch van Beijnum wrote: > > > On maandag, sep 8, 2003, at 17:30 Europe/Amsterdam, Dean Anderson wrote: > > > > >> Nobody cares. Making a roof 100.000000% impervious to water molecules > > >> may be impossible, but that doesn't mean we have to resign to getting > > >> wet every time it rains. > > > > > People care because when someone comes around saying "you can have a > > > 100% > > > impervious roof if only you jump through these inconvenient hoops", we > > > know that they are wrong, and don't need to waste time considering how > > > inconvenient the hoops are. > > > > Your analogy doesn't fly. Our email protocols have holes big enough to > > drive a truck through. Is it unreasonable when people ask the IETF > > leadership for a place to work on this? > > I don't think our email protocols have any holes at all. They can be > abused. But mere abuse is not a "hole". > > > > "We", meaning the IETF, care, because this is very useful aid to > > > deciding what to work on. We know that we need to focus on leak > > > stoppage, not trying to invent leak-proof protocols. There is no > > > point researching something that is impossible. > > > > Let's first define our goal before declaring it impossible to reach. > > Well, I think the goal has been stated: Create an abuse-free email > protocol. That goal is impossible. Thus, we have abusable protocols. > > Perhaps you have a different goal in mind, but it doesn't sound like you > accept the premise that it impossible to create an abuse-free protocol. > > > >>> After I first posted this on IETF a while back, someone suggested > > >>> that covert channels require cooperation, and that spam therefore > > >>> isn't a covert channel. > > > > >> Where does this covert channel stuff come from anyway? > > > > > What do you mean? > > > > The jump from "spam" to "covert channel" isn't immediately obvious. And > > if any proof of why spam is a covert channel has been offered, I've > > managed to miss it. > > The NCSC's definition refers to ANY communication not authorized by the > security model. Note that the term "Covert Channel" is frequently > associated with Multilevel Secure Operating Systems. The liturature uses > other terms to describe the same concept: "information leakage", "sneaky > signalling", "hidden data flows", "side channels". So you must not get too > caught up in the peculiarities of operating systems. The concept is quite > general. > > It is immediately obvious that covert channels have 3 characteristics: It > is a CHANNEL, it is COVERT, and it VIOLATES SECURITY POLICY. (Caps for > emphasis of definition, not loudness.) > > > CHANNEL: Spam is a type of Email. Email is a channel transfering signals > from A to B. Email is really a subchannel of the internet, which is a > subchannel of the PSTN, public and private fiber networks, etc. > > COVERT: Spam is hidden in so far as possible from the system operators. It > is an unintended communication in that the system operators intended that > only non-broadcast, solicited commercial communication flow. This not an > exclusive list of what is permitted, but illustrates that spam isn't > permitted. > > VIOLATES SECURITY POLICY: System Operators specified an acceptable use > policy that outlines what is permitted and what is not permitted. UCE is > not permitted. Various methods have been implemented to enforce this > policy. > > > > >> the spammer's achilles heel is that they need to send out incredible > > >> amounts of email in order to fulfill their objectives, whichever > > >> those are. Detecting bulk mail is doable, and it shouldn't be too > > >> hard to come up with something to differentiate legitimate bulk > > >> emailing from spam. For instance, we can reverse the burden of proof > > >> here and only allow know bulk emailers. > > > > > "Detecting abuse" is quite different from making a protocol that can't > > > be abused. > > > > If you can detect abuse on input rather than on output, detecting abuse > > is exactly what enables you to make an abuse-free protocol. And again: > > just because there are situations that you can't do something doesn't > > mean it's automatically useless to perform the action under other > > circumstances too. > > Input to the first mailserver is output to the mail client. There may be > many input/output connections. For every input, there is an equal and > opposite output. (Seems that perpetual motion may have some analog after > all ;-) > > > > But that is my point: You have to focus on detection. This > > > doesn't require any protocol changes whatsover. > > > > Do you mean first accepting the message, then searching for anatomical, > > pharmaceutical or financial terms and subsequently discarding the > > message? This is useless as it only makes the spammers spam more, not > > less. > > > > > We are already "only allowing known bulk emailers". > > > > Untrue. > > Speak for yourself. > > > > Unfortunately, that doesn't prevent spam. > > > > It should help if used together with some kind of authentication (for > > which, I'm happy to see, there are several independently submitted > > proposals on the table) so that spammers can't inject arbitrary from > > addresses. > > Spammers can _always_ do whatever regular users can do. There is no way to > authenticate regular users and not authenticate spammers. This is why SMTP > AUTH has no effect on spam. If regular users can inject arbitrary > addresses, then so can spammers. Regular users can always inject > arbitrary addresses. Ordinarilly, this is desired. > > > > Indeed, it seems most of the spam isn't commercial: Most of the spam > > > seems to come from viruses, and isn't really selling anything. > > > > The point being? > > The point being that the persons sending most of the spam will do anything > to annoy people. It has no grounding in commercial motivation, nor can > regulation of commercial activity have any effect. In other words, > protocols that require cooperation of the spammer aren't likely to > succeed. > > > > The viruses can use the credentials of the infected user. That is > > > "legitimate", until someone reading the email realizes its not and > > > complains. These send 40-50 messages per IP, and is hard to detect as > > > bulk. But when added up over a lot of IP addresses, is quite obviously > > > annoying. > > > > Not as annoying as "real" spam. (Although the size of email worms is > > unpleasant. Fortunately, regular spam is usually pretty small.) > > You miss the point. Most of the "little" spam is sent by virus infected > computers as well as email containing the virus itself. > > > >> Fixable with authentication. > > > > > No, that's the point. It isn't _fixable_ with authentication. It isn't > > > fixable at all. It is only "fixed" when the spammer loses his account. > > > Then the spammer gets a new account. So it isn't really fixed. > > > > It is when they lose their accounts faster than they can acquire new > > ones. > > Has this ever happened in 8+ years? No. Will it ever happen? No: ISPs > aren't ever going to terminate accounts immediately on someone elses > say-so. First, it wouldn't be good business not to investigate > accusations, second, it wouldn't be legal, and third, the blacklists have > a terrible record of abuse, themselves. > > The spammer already has authentication, however it was acquired: Stolen, > disposable, etc. Email authentication will always be equivalent to that > authentication. The user either has both, or they have neither. If they > lose their account, they lose both. It is unnecessary to add more > authentication. An engineer should know that two variables that always > have the same value can be replaced by one variable. > > The notion of authentication in email comes from the fallacy that spammers > are somehow outsiders getting in. They are not outsiders. They will never > be outsiders. It is impossible to construct a protocol that makes them > outsiders, any more than it is possible to make a protocol that keeps out, > say, democrats. > > > > So we are always going to be playing a game of whack-a-mole. > > > > So? I don't mind doing that if I can win. Having to play and then be > > forced to lose is much harder to swallow. > > You can only win by detection and suppression. Suppression has to happen > faster than account termination. The only way that can happen is by > filtering the recievers email. > > > > That cannot be avoided by altering the protocol or the authentication > > > scheme (information theory proves this). So it is useful, then, to > > > work on ways of detection, and improve our whack-a-mole skills. > > > Altering protocols and authentication is a waste of time. > > > > I find it unacceptable that my email software lets people bombard me > > with crap while at the same time faking the headers such that said crap > > seems to come from an innocent bystander. I can't understand how any > > reasonable person can think this is ok. > > People find it unacceptable that fertilizer explodes. However, it is > impossible to make fertilizer that doesn't explode. Only those ignorant of > chemistry call for such things. > > > Or maybe we should just go ahead and move the "From: " header to > > historic and be done with it. > > Might as well add all the other headers than can be forged as well. Might > as well take the From Address off postal mail as well, since that can be > forged, too. It is a mistake to think that just because something can be > abused, that it should be removed. > > --Dean > > > >