On Mon, 26 Aug 2002 21:12:40 +0200, Jeroen Massar <jeroen@unfix.org> said:

IMHO, Paul's idea is quite a good one, but all servers will need to be upgraded, and all dns entries installed.

Given the number of providers who seem to think ingress and/or rfc1918 filtering shouldn't be done, what makes you think that "all servers" will be upgraded to support THIS proposal? (If you don't want to re-start the RFC1918 war, feel free to substitute ANY OTHER thing that most people think is a Good Thing, but we've seen some sizable minority not deploy for reasons they consider perfectly valid). -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech

On Mon, 2002-08-26 at 13:43, Jeroen Massar wrote:

Read my sentence again, because I really won't see everybody install/use it. One can also simply see so by the problems related to the fact of installing security updates. Some 'companies' and individuals are simply too sleezy/lousy or whatever to do it. And thus open spam relays will be kept alive which is why there are RBL's.

This will only help a bit, and tools like SpamAssasin/Razor will keep a load of stuff of your servers.

Paul's proposal doesn't require battening down every mail server out there either. The particularly useful aspect of this approach is that clueful administrators of more visible mail servers can cut down on being spoofed. This would also be specifically effective against Klez and similar annoyances. It doesn't matter if the spammer/virus is cooperating with the system or not. If the final destination contacts the mailfrom callback server, and it says "This definitely isn't legitimate" then even with a small adoption rate, there will still be a significant decrease in cruft, and the mail system being spoofed has something better to point at when they get flooded with complaints from people who actually trust the <mail from> field. But then, all this is fairly clear in the draft. I can't figure out why it hasn't been more widely accepted as a Good Idea. The presumably appropriate topic for discussion on this list is why a system such as this would be a problem for network operators who choose not to implement such a callback feature. So far the only objection I've seen is "It won't make any difference" and that seems to be a flimsy argument. Please correct me if I'm missing something.

Making it harder to get into your house is better than putting the doors wide open... Every bit helps...

Exactly. -dvd

On 03:07 PM 8/26/02, Barry Shein wrote:

Let me throw out the following to show how blind the technical community has been:

There is no RFC or other public standards document which even attempts to define spam or explain, in a careful and professional manner, why it is a bad thing.

(before you say the obvious, that's not what RFCs are for, read, e.g., RFC 2964)

I guess you haven't read RFC 3098 yet then. http://www.geektools.com/rfc/rfc3098.txt How to Advertise Responsibly Using E-Mail and Newsgroups or - how NOT to $$$$$ MAKE ENEMIES FAST! $$$$$ Table of Contents 1. Introduction .............................................. 2 2. Image and Perception of the Advertiser..................... 4 3. Collateral Damage ......................................... 5 4. Caveat Mercator ........................................... 5 5. Targeting the Audience .................................... 7 6. Reaching the audience ..................................... 8 A. Dedicated website or web page ........................ 8 B. "Shared" Advertising website ......................... 9 C. Netnews and E-Mailing list group postings ............ 10 D. Compiled E-Mail Lists ................................ 11 7. Opt-In Mailing Lists ...................................... 12 A. Privacy ................................................ 13 B. Integrity .............................................. 13 C. Protection ............................................. 16 8. Irresponsible Behavior .................................... 16 9. Responsible Behavior ...................................... 17 10. Security Considerations ................................... 19 Appendices .................................................... 20 A.1 The classic Pyramid .................................... 20 A.2 What about Ponzi? ...................................... 22 A.3 So all multi-levels are evil? .......................... 22 B.1 Why Web Privacy? ....................................... 23

Every single purely technical approach to stopping spam has been a complete loser.

In the fullness of time, the universe itself will die of heat. So what? What matters more is what use is made of time before it gets so "full." A number of purely technical approaches to stopping spam have been quite successful... in the short term... which not the same as being a complete loser in the long term. (Everything's a complete loser if you measure it right.)

There is no RFC or other public standards document which even attempts to define spam or explain, in a careful and professional manner, why it is a bad thing.

Someone else already quoted an RFC from geektools that contains such a definition. http://www.mail-abuse.org/standard.html, on the other hand, is something I cowrote back when I still had an operational role at MAPS, and still seems pretty careful and pretty professional (and pretty public.) -- Paul Vixie

Barry, I have a wrench :) Everything looks like a nut to me. But in all seriousness. I have to agree with Barry's statement here. Spam is very much a social, political, ethical, and financial issue. Filters are static things, that have to be updated, and can't see every case that comes thru. Even the Habeas idea, while novel and interesting, requires people to do quasi technical things. The average user isn't going to do those things. Much spam comes from relay servers outside of north america, but is targetted towards us yanks. Until we make the social or financial impact real enough to stop the spammers, they will continue. Enough people respond to spam, that its worth it to them to sell there warez via this method. I think we geeks would spend better time, trying to help adjust the social and financial changes, instead of smashing on the the bolt with the hammer... A stab at defining SPAM: The sending of email to a person, where there is a financial gain (directly or indirectly) to the sender, and where the receiver did not expressly request such email. Please DO NOT reply to my definition on the NANOG list, else the NANOG police will get you..... john brown speaking for me On Mon, Aug 26, 2002 at 06:07:46PM -0400, Barry Shein wrote:

Point of Information:

Every single purely technical approach to stopping spam has been a complete loser.

I understand the old adage that when all you have is a hammer the whole world looks like a nail.

And that all many people on this list have is a technical hammer, some ability to hack around with cisco access lists or similar, so they tend to hold out hope that some new access list formula might be the one that saves the day (or similar, don't quibble the example!)

But spam is as much a socio-legal problem as a technical one which is why, I'd claim, it's been so completely resistant to all purely technical approaches thus far.

What we need are technical solutions which help with concomitant socio-legal solutions.

If you haven't noticed, the spammers are winning completely, the waters are rising rapidly.

More and more legitimate-sounding companies and products are spamming, and by and large the public perception in the non-anointed* business community are coming to the conclusion that they receive all this spam so it must be a legitimate form of advertising.

Let me throw out the following to show how blind the technical community has been:

There is no RFC or other public standards document which even attempts to define spam or explain, in a careful and professional manner, why it is a bad thing.

(before you say the obvious, that's not what RFCs are for, read, e.g., RFC 2964)

However, we expect lawmakers to recognize and define the problem and get it right when the engineers who understand the technology and problem, in nearly a decade of whining, can't even be bothered to provide them with robust definitions of what it is the whining is about.

Food for thought, that's all.

But, personally, I'm hesitant to spend my time trying to study the merits of yet another anti-spam miracle cure, even if it seems at first glance (like so many before) that it might foil some particular flavor of spam which has been prevalent in the past.

Now, after sitting through this extended, multi-day discussion of spam someone can send me the standard "discussion of spam is not a subject for nanog!" because I'm not a member of the amen crowd.

* "non-anointed": not a member of the technical community hence indoctrinated into a particular ethical view of what's right and wrong on the net.

-- -Barry Shein

Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD The World | Public Access Internet | Since 1989 *oo*

As a user, I pay my ISP to forward IP packets. If there happen to be TCP segments in those packets, that's something between me and the person the packet is addressed to, ...

...and, occasionally, your ISP's "abuse desk." If this function of your ISP costs less than 1 FTE per 10,000 dialups or 1,000 T1's or 100 T3's, then your ISP is a slacker and probably a magnet for professional spammers as well. If they want to do some simple things to keep the "slacker" cutoff point at those numbers rather than other numbers which are 90% smaller, you'll understand the economics. If one of those simple things is blocking outbound TCP/25, then I hope you have alternatives including changing ISP's... ...but if you don't, then it's between you and your ISP, and best of luck. -- Paul Vixie

On Mon, 2002-08-26 at 21:08, Paul Vixie wrote:

...and, occasionally, your ISP's "abuse desk." If this function of your ISP costs less than 1 FTE per 10,000 dialups or 1,000 T1's or 100 T3's, then your ISP is a slacker and probably a magnet for professional spammers as well. If

Not to try to undercut the general point, but that would imply that Earthlink, AOL, and MSN (for examples) should have a combined abuse department of roughly 1500 employees. Well, perhaps those were poor examples then. It would be wonderful if it were the case, and while it seems like laziness when we talk about the big guys, most middle sized providers just don't have the operating budgets to not slack at least a little bit. The simple things you referred to would be designed to make the function of abuse personnel / subscribers look more logarithmic, but this whole thread and all the other arguments stem from the fact that it really isn't that simple. Spam is a social problem, but no one seems to think that solving it socially (a la paying for well staffed abuse departments) is the answer. So as you suggest, the solution is a combination of social and technical answers, keeping that personnel ratio manageable. But this debate (I'm not debating with *you*) keeps coming around full circle. Perhaps the real social problem is convincing whatever standards bodies and vendors necessary that it is a technical problem. There seems to be far too much apathy (FUD?) rather than just designing a partial solution, however imperfect, and implementing it. -dvd

vixie@vix.com (Paul Vixie) writes:

whenever you get spammed, it's because some isp somewhere is a slacker,

what i meant to say was "whenever you're getting repeat spam from the same place, day after week after month, it's because some isp somewhere is a slacker." any given isp can be attacked and used to send outbound spam. but not every isp can be used in this way over and over by the same bunch of people. to the second group, i say: "please shift the cost of dealing with spam from your network, back inside your network." -- Paul Vixie

At 7:43 AM +0000 2002/08/27, Paul Vixie wrote:

i doubt they will comment in detail here, since the actual numbers are likely to be some kind of internal secret. i know i get far less spam from AOL than i used to, and i've assumed that this is because they decided to address the costs at the front end (in their service model) rather than the back end (in endless cleanup.)

They have implemented a lot of internal controls for users of the AOL client. For dial-up users trying to directly transmit mail, they have to pass through the transparent SMTP proxy which the AOL personnel set up and explicitly requested that it be added to the MAPS RBL. So, one way they have to deal with the AOL internal controls, and the other way they are already blacklisted.

no solution which does not progressively leverage the combined small efforts of millions of spam victims will ever be measurably effective other than in some small locality and/or for some brief instant. see the DCC for an example (http://dcc.rhyolite.com/) of how to build and apply that leverage. (i'm not giving the reference to vipul's razor because i said "millions.")

Indeed, that is a cool idea. I definitely want to look into that a lot more closely. Perhaps we can combine this with deep blacklist checking (beyond just the first hop), tagging, and Bayesian content filtering. Perhaps then we will have a temporary pass at a semi-decent anti-spam filter. -- 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(+++)

--On Monday, August 26, 2002 10:34 PM +0200 Iljitsch van Beijnum <iljitsch@muada.com> wrote:

As a user, I pay my ISP to forward IP packets. If there happen to be TCP segments in those packets, that's something between me and the person the packet is addressed to, whether the destination port of those TCP segments is 25 or something else.

Hear, hear! I run an email-only service provider (www.imap-partners.net), and we have to help certain users over the threshold at e.g. Earthlink by permitting them to reach us on another port. This is logically ridiculous, and bound to change. Earthlink's behavior here may have some positive social benefit, but there is a downside. If it becomes impossible for my customers to reach me and do SMTP AUTH, I will be out of business. The network is not the application, and should not be.

At 9:12 PM +0200 2002/08/26, Jeroen Massar wrote:

ISP's should actually block port 25 outgoing, or even better, reroute/forward it to their own mail relay.

Agreed.

This will force people to use their upstreams email address though when sending email outbound.

Yup.

IMHO, Paul's idea is quite a good one, but all servers will need to be upgraded, and all dns entries installed.

I still think that it causes problems for mailing lists. Moreover, you need to know the complete outbound path for all e-mail, from soup to nuts, so that you can add all those machines to the list of known mail-from MX entries for your domain. I'm sorry, complete information like this just doesn't exist anymore. Knowledge like this did exist twenty or more years ago, back when there were only a few UUCP nodes. But even then, things quickly got to a point where people couldn't possibly know all possible paths between any two points, and people just listed their address from a small set of "well known" nodes.

Unfortunatly that will take some time, installing a tool like spamassasin/razor etc is much more effective even though those tools won't stop spammers.

I disagree that it would stop spammers. Even if everything else worked, all it would require is that they get more creative in faking e-mail addresses. They just have to make sure that when the mail is delivered to you, it comes through a machine that is on the list of MXes for the mail-from entry for the domain. Put a simple wildcard MX in there (and nothing else), and it should match anything. Moreover, even if all servers on the Internet were secured in this manner and there were no open relays, it would also require perfect reverse DNS because the MXes are listed by name and not IP address -- that's assuming you do a reverse lookup on the IP address and require that the returned name is on the list. If you do a forward lookup (taking each of the listed MXes for mail-from and looking up their IP address), that would require that no one use DNS-based or geographical-based load-balancing, because then the forward lookup on the name might not match the IP address of the sending relay.

At least it will help a bit against one of the bigger internet "problems".

I agree with the overall IETF approach of implementing something and seeing if it works (as opposed to talking things to death), but this is a case where I fear that the proposed solution could only work in a perfect world, and even then it would have some serious problems. -- 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(+++)

Randy Bush wrote:

...

...

ISP's should actually block port 25 outgoing, or even better, reroute/forward it to their own mail relay. Agreed.

why not do it to port 80 as well? what the hell, why not do it to all ports? who the hell needs an internet anyway, let's all have a telco walled garden.

<string of expletives>

can we get back to operating the internet, not killing it?

<another, even longer, string of expletives>

Nice rant Randy, but if you even ever wondered why the wording "Mail Relay" exists you might see that if an ISP simply forwards all outgoing tcp port 25 traffic to one of their relays and protects that from weird spam addresses as a source and only allowing through configured addressess it would save you, me and the rest a load of crap which maybe could "kill the internet"... We didn't invent stuff like SMTP, POP3, IMAP and stuff to be run on EVERY single node on the internet. Indeed it limits your clients, just like a NAT does, just like firewalling does, but it also saves a load of problems. And maybe your view is "operating the internet" but some people have a too busy spam/abuse@ mailbox to be able to do usefull stuff like tracing ddosses, which is yet another thing people should do but aren't doing: egress filtering. If (and if) everybody did that, we wouldn't be seeing spoofed addresses, rfc1918's and other stuff on the internet either now would we? So pointing these facts out *HAS* something to do with "operating the internet". <hint> http://as112.net/ </hint> Greets, Jeroen

John Kristoff wrote:

On Tue, 27 Aug 2002 00:59:49 +0200 "Jeroen Massar" <jeroen@unfix.org> wrote:

...

Nice rant Randy, but if you even ever wondered why the wording "Mail Relay" exists you might see that if an ISP simply forwards all outgoing tcp port 25 traffic to one of their relays and protects that from weird spam

The point is that 25 is just a number. You'll eventually be blocking all numbers sooner or later (and re-inventing dumb terminals).

Another person who can't read. SMTP is a protocol which is based on relaying messages from one mailserver to another. An endnode (especially workstations) don't need to run SMTP. ISP/Company's already have SMTP servers which are setup to relay for their clients. So what's so bad about forwarding all tcp/25 traffic over that relay and letting that relay decide if the MAIL FROM: is allowed to be relayed? And if a client wants to mail from another domain which isn't relayed by it's upstream ISP, he/she could ask it's ISP to do so. Yes this will add an administrative hassle, but doesn't spam imply that also? The whole problem is yet again that a small amount of people (this time spammers) make a whole lot of problems for a lot of people (we). Also this setup is somewhat the same as checking from an smtp-server whether the sending server is also actually running an smtp... Fortunatly we got SpamAssasin/Razor nowadays so the spam that does get through gets filtered out without bothering me or anybody else using these tools. Greets, Jeroen

$author = "John Kristoff" ;

I'm not sure how to truly disable an SMTP server from running on an end host. You can block or force forward port 25, but that is just a number. Be prepared to start doing that for all ports, then protocols, then IP addresses, then protocols again.

but surely an MTA derives it's usefulness by running on port 25. i don't remember reading about where in the DNS MX RR you could specify what port the MTA would be listening on... marty -- My Everest is not in Nepal, She's sleeping in the bedroom second right down the hall. Ed Hiliary couldn't crack this nut, He'd be hiding in the lounge room with the rest of us. "My Everest" - Lazy Susan

$author = "John Kristoff" ;

On Tue, Aug 27, 2002 at 12:14:46PM +1000, Martin wrote:

...

but surely an MTA derives it's usefulness by running on port 25. i don't remember reading about where in the DNS MX RR you could specify what port the MTA would be listening on...

Surely your not a spammer looking for tips are you? :-)

hardly. just someone who has tried blocking traffic to dialup pools with DST port 25 and forced relay on all outbound traffic with DST port 25. it worked... for some values of worked. as most would know we broke smtp-auth for a small handful of people that were trying to use it. as joe pointed out to me privately RFC 2782 specifies SRV RRs which could be used to point an MX.SRV at a port other then 25. anyone got any examples of MTAs or MUAs that implement said RFC? marty -- My Everest is not in Nepal, She's sleeping in the bedroom second right down the hall. Ed Hiliary couldn't crack this nut, He'd be hiding in the lounge room with the rest of us. "My Everest" - Lazy Susan

-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Martin Sent: August 26, 2002 10:15 PM To: nanog@merit.edu Subject: Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)

but surely an MTA derives it's usefulness by running on port 25. i don't remember reading about where in the DNS MX RR you could specify what port the MTA would be listening on...

Well, it must specify it somewhere, since at least a couple of times a week we have our users ask how to stick a port number in an MX record. :) Where they got this idea is beyond me (unfortunately), but it's quite a common question... Vivien -- Vivien M. vivienm@dyndns.org Assistant System Administrator Dynamic DNS Network Services http://www.dyndns.org/

Force forward by default, but allow anyone who wants to use TCP port 25 the ability to do so. They must sign an non-abuse agreement or whatever. Then they get their host/link put into the TCP port 25 open path.

Every ISP I have ever worked for and every ISP I have ever used has eventually been convinced by me to come around to this policy. Do whatever you want by default, but let trusted/clueful people opt out of it and just get their IP datagrams from point A to point B. I personally wouldn't sign an agreement with an ISP that allowed them to molest my traffic in this manner unless it allowed me to opt out of it. I've seen the headaches such assumptions about what everybody else needs/wants to do can cause. DS

On Mon, 26 Aug 2002, Brad Knowles wrote:

I still think that it causes problems for mailing lists.

I understand the proposal to be based on the envelope sender, not the sender in the body. Hence, mailing lists work, because they are the envelope sender, not the person who submitted the mail to the mailing list. If that is not the case, then Paul needs to be hassled until the wording is clear that mailing lists will continue to work.

Moreover, you need to know the complete outbound path for all e-mail, from soup to nuts, so that you can add all those machines to the list of known mail-from MX entries for your domain.

I'm sorry, complete information like this just doesn't exist anymore. Knowledge like this did exist twenty or more years ago,

Pardon? Are you saying that for a given entity (say, example.com), your administrative procedures are such that you do not know all the machines that can send email directly to that part of the Internet outside that entity? Even for an entity like aol.com, their outbound mail servers appear to be a small(ish) set of circa 20 machines which can be listed appropriately by AOL.

back when there were only a few UUCP nodes. But even then, things quickly got to a point where people couldn't possibly know all possible paths between any two points, and people just listed their address from a small set of "well known" nodes.

Yes, entirely correct. However, the bulk of the Internet mail today is from one host to another host. Knowledge of the path the mail takes, on the SMTP level, is not needed by the mailer, unlike UUCP which required the mailer to be aware of various routing topologies. The rest of your mail is an invitation to clean up the little bit of forward and reverse domain space that is under your immediate control, which is a Good Thing IMO. --==-- Bruce.

At 12:16 PM +0200 2002/08/27, Bruce Campbell wrote:

I understand the proposal to be based on the envelope sender, not the sender in the body. Hence, mailing lists work, because they are the envelope sender, not the person who submitted the mail to the mailing list.

Read my previous comment about mailing lists that do not change the envelope sender (e.g., mailing lists that are instead run as simple aliases).

Pardon? Are you saying that for a given entity (say, example.com), your administrative procedures are such that you do not know all the machines that can send email directly to that part of the Internet outside that entity?

Not if example.com is a vanity domain and is not allowed to transmit mail directly to the outside world, or actively chooses to use the relay services provided by their ISP. You may know the entry point, but it can be difficult to determine all the possible exit points.

Even for an entity like aol.com, their outbound mail servers appear to be a small(ish) set of circa 20 machines which can be listed appropriately by AOL.

I know. I set those machines up. They haven't really changed much since I left in '97. But try listing 20 different names as MXes for a mail-from label. Have you heard of this thing called "DNS response truncation"? Do you know the kinds of problems it causes for many MTAs, even today?

Yes, entirely correct. However, the bulk of the Internet mail today is from one host to another host. Knowledge of the path the mail takes, on the SMTP level, is not needed by the mailer, unlike UUCP which required the mailer to be aware of various routing topologies.

It is if you have to know all the possible exit points for e-mail that you may transmit.

The rest of your mail is an invitation to clean up the little bit of forward and reverse domain space that is under your immediate control, which is a Good Thing IMO.

Indeed, it would be good to get this cleaned up. But let's be realistic. When you have 256 total gTLDs and ccTLDs (plus the root zone), served by 762 unique machines, and 413 of those machines are open public/recursive nameservers in addition to their authoritative duties, leaving everyone underneath 204 TLDs susceptible to attack via cache poisoning at one or more servers for their TLD, you realize that there are much more serious problems that have to be solved. -- 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(+++)