On Tue, 13 Apr 2004, John Curran wrote:

I'm very much suggesting blocking outward to the Internet port 25 traffic, except from configured mail relays for that end-user site. Those hosts which have MSTP malware are stopped cold as a result.

NNTP is set up almost everywhere with configured server to server connections, and essentially all "open" NNTP user access has been closed down over the years. How is the spam problem on USENET these days?

On 13-apr-04, at 22:32, Sean Donelan wrote:

...

I'm very much suggesting blocking outward to the Internet port 25 traffic, except from configured mail relays for that end-user site. Those hosts which have MSTP malware are stopped cold as a result.

NNTP is set up almost everywhere with configured server to server connections, and essentially all "open" NNTP user access has been closed down over the years.

How is the spam problem on USENET these days?

I've been on Usenet again for a while last year and there was surprisingly little spam compared to some years back. Apparently some people have taken it upon themselves to remove all the spam that pops up. NTTP is at an advantage over SMTP here because "personalizing" messages for each recipient isn't possible here. Talking about lazy: blocking port 25 is very lazy, in several ways: intelectually, morally and just plain way. It's intellectually lazy because there are other ways to arrive at the same result that don't arbitrarily block communications between two consenting hosts. Morally it's lazy to assume that just because you don't need something, others won't either. And of course having all those access networks install filters rather than work on the problem yourself is just plain lazy. If we all agree that we don't want to talk SMTP to broadband consumers, it shouldn't be too hard to come up with a registry that lists IP addresses used by broadband consumers. Or maybe it's easier to work the other way around and list the servers we actually may want to talk to. This approach has two main advantages over filtering port 25: 1. People can still talk to unlisted SMTP hosts if they feel they have a good reason to do so (ie, I get to deliver messages directly to my server from home rather than being forced to use my service provider's which may or may not work) 2. Checking is done per SMTP session rather than per IP packet The good news is that the IETF is now starting work on this, so expect results in two or three years.

The reality is that the vast majority of email is handed off to a designated mail relay (whether we're talking about consumer connections or office environments), and if we actually configured connectivity in this matter, there wouldn't be a problem.

our innate fear of this stems from suspicion of centralization and the telco switch model. this fear is not clearly unjustified. maybe we can get reasonable security without a police state? randy

At 5:38 PM -0700 4/13/04, Chris Palmer wrote:

When evaluating spam solutions, the first thing I ask is, "Does this empower users?" If the answer is no, it's probably the wrong solution.

That's definitely the right idea to start with... The question is, do you change approach after a decade without progress? /John

chris@eff.org (Chris Palmer) writes:

When evaluating spam solutions, the first thing I ask is, "Does this empower users?" If the answer is no, it's probably the wrong solution.

right now the spammers are holding the users hostage: "if you want to be able to read mail from people/hosts you've not been formally introduced to, then you have to swallow our swill also." that's somewhat the opposite of empowerment. if a "spam solution" can take away that crisis and the expense is that my dsl-connected end host has to tunnel its e-mail to someplace out in <www.vix.com/personalcolo> then that's a tradeoff i can live with. -- Paul Vixie

Chris Palmer wrote:

When evaluating spam solutions, the first thing I ask is, "Does this empower users?" If the answer is no, it's probably the wrong solution.

Spammers are users too. You can't spell "abuser" without "user." You are inherently trying to diminish the power of the abuser users. No spam mitigation solution can ever answer, "yes," to that question without the qualification that at least some users, the abusers, will be disempowered. The equation will always come to balancing how hard you hit the spammers versus minimizing the collateral damage. Or it's another classic example of security versus usability. -- Crist J. Clark crist.clark@globalstar.com Globalstar Communications (408) 933-4387

On Wed, 14 Apr 2004, Randy Bush wrote:

...

The reality is that the vast majority of email is handed off to a designated mail relay (whether we're talking about consumer connections or office environments), and if we actually configured connectivity in this matter, there wouldn't be a problem.

our innate fear of this stems from suspicion of centralization and the telco switch model. this fear is not clearly unjustified.

There are also plenty of legitimate reasons to permit earthlink/juno/mindspring dialup users to hit mail relays on their own domains. For instance, when on travel how does John Curran access his istaff.org email? (presuming no 'ssh to my shell server and use pine/elm/mh/mailx)

maybe we can get reasonable security without a police state?

What will the jack-booted-thugs do then? :)

On Wed, 14 Apr 2004, Randy Bush wrote:

...

...

maybe we can get reasonable security without a police state? What will the jack-booted-thugs do then? :)

tell us how to close down other parts of the net so they can control and profit from them

Ah-ha! too bad that mean old IAB says we can't filter traffic :) (or advises against it, or thinks it's a bad idea...) In all seriousness, the consumer dial/broadband folks had to take actions like port/25 filtering (inbound and outbound actually) to address spam issues with these systems. This is unfortunate for those folks out there that 'need' smtp access to something other than the blessed email servers of their dial/broadband provider(s). Making a more sensible solution for email than the current SMTP, or finding a middle ground that works for dial/broadband users would sure be nice. Any 'port 25' filtering is really just a short term solution until all spambots use locally configured SMTP settings to bypass the filtering :( (atleast that seems to be the case with the spamwar in general, a constantly escalating war of technologies) Perhaps finding a way to make spam non-profitable, or to put enough of the high-end spammers in jail? this seems like a daunting task I must admit :( -Chris

Are there any other Service Providers who have been allocated blocks out of the 83/8 network that are experiencing connectivity issues? We have been allocated 83.146.0.0/18 and customers on this network have difficulty getting to sites like www.mercer.com, hk.yahoo.com etc..etc.. I'm just interested if it is a general BOGON filter issue still or whether this is more specific to our network. Cheers Simon Brilus Bulldog Communications Ltd.

I'm seeing the same thing: works from 80.*, doesn't work from 83.*. Note that www.mercer.com seems to suffer from a bad case of paranoia, they filter traceroute and ping, so probably a misconfigured firewall there. hk.yahoo.com traceroutes just fine from a 212.* address:

TCP port 80 can also be used to traceroute... hping is your friend. http://www.hping.org (or apt-get install hping2 on apt-friendly distributions) Rubens

In message <p06020407bca227be1be3@[192.168.1.101]>, John Curran writes:

The reality is that the vast majority of email is handed off to a designated mail relay (whether we're talking about consumer connections or office environments), and if we actually configured connectivity in this matter, there wouldn't be a problem.

John, the problem is deciding who is an *authorized* email sender. For example, I own a machine in a random rack -- can it send email? The way I operate, it sometimes needs to -- I often set up tunnels to it from my laptop and from other machines in "banned" address ranges, and let it send my email. For that matter, it hosts several IETF and personal mailing lists. Now assume that someone in some strange and wondrous part of the world has a similar need. Are they authorized? According to whom? There have been a lot of authentication-based and filter-based schemes proposed, but I've yet to see a scheme that solves the authorization problem satisfactorily. Not everyone wants to (or is able to) entrust their email to a a Tier 1 ISP; if nothing else, the Tier 1s would charge for the privilege. --Steve Bellovin, http://www.research.att.com/~smb

In message <p06020409bca2403fda31@[192.168.1.101]>, John Curran writes:

...

At 8:36 PM -0400 4/13/04, Steven M. Bellovin wrote:

Now assume that someone in some strange and wondrous part of the world has a similar need. Are they authorized? According to whom?

Steve, you're authorized if you say you are and agree to accept responsibility . Most corporations would readily provide the addresses of their mail servers; anyone on DSL or cable connection could do the same. But by changing the default behavior to block port 25 until requested, you could readily address t he spam problem. It would take some work on the part of operator community (hence the subject), and doesn't fit in the world wide commune perspective of networking, but it would make the Internet far more useful for everyone.

The spammers are already creating throw-away domains; they'd do the same with mail sender authorizations. "I am Spam, Spam I am" -- and send their turds and run. --Steve Bellovin, http://www.research.att.com/~smb

Steve, you're authorized if you say you are and agree to accept responsibility. Most corporations would readily provide the addresses of their mail servers; anyone on DSL or cable connection could do the same. But by changing the default behavior to block port 25 until requested, you could readily address the spam problem. It would take some work on the part of operator community (hence the subject), and doesn't fit in the world wide commune perspective of networking, but it would make the Internet far more useful for everyone.

(I realize I'm a few days late on this, been travelling all week) What about that small business with a remote site on a cable modem? All they want is their local server to talk to the one upstream, and they'd rather pay, say, Time Warner $50 a month on a dynamic instead of $200 for a single static IP. Can't really blame them, can you? Is this authorization-filter-scheme going to account for servers on dynamic IP? Rob Nelson ronelson@vt.edu

On Wed, Apr 14, 2004, Michael.Dillon@radianz.com wrote:

...

Not everyone wants to (or is able to) entrust their email to a a Tier 1 ISP; if nothing else, the Tier 1s would charge for the privilege.

A tier 1 provider in the SMTP mesh does not have to be the same thing as a tier 1 provider in the physical mesh. See the structure of the NNTP mesh over the years for examples. I fully expect to see specialized email peering providers arise who will have SMTP peering arrangements with the large email site like AOL, Yahoo, Hotmail etc. and who then arrange peering with large numbers of smaller sites who either cannot find SMTP peering locally or who want to be assured of alternate SMTP routes in the event their main peer cannot reach all destinations.

.. and then I pay my upstream for the privilege of them sending my mail along for me? All of that equipment so a bunch of universities can feed their upstream a whole chunk of email reliably isn't exactly going to be cheap. These specialised email providers are going to have to have _some_ form of transit to handle 'just email', increasing the cost. I wonder how many backbone providers want to run their own email gateways for all email passing through their network and have to provide some form of guaranteed service to their customers. I wonder how this is going to affect SMTP mail handling as it stands - for example, how many 'hops' will there be between this university's mail gateway and, say, MIT's mail gateway(s)? Will people start playing header rewrite tricks so MTAs around the world don't bomb out with "exceeded hop count" ? "Just one hop!" games, a la IP routing in the final stages of last century, may rear its ugly head again. I don't believe comparing this to NNTP is entirely valid - you don't have the overhead of multiple crazy NNTP server implementations causing you the utmost of pain; you don't have to worry about handling bounces and temporary DNS failures along each path; article routing (whether you chose push or pull) was much, much simpler. Adrian -- Adrian Chadd I'm only a fanboy if <adrian@creative.net.au> I emailed Wesley Crusher.

On 14-apr-04, at 11:50, Petri Helenius wrote:

...

I wonder how this is going to affect SMTP mail handling as it stands - for example, how many 'hops' will there be between this university's mail gateway and, say, MIT's mail gateway(s)? Will people start playing header rewrite tricks so MTAs around the world don't bomb out with "exceeded hop count" ? "Just one hop!" games, a la IP routing in the final stages of last century, may rear its ugly head again.

Could the MTA´s run something similar to MPLS so they could reduce the hop count and "funnel" the email though instead of storing and forwarding it hop by hop? Maybe some users would then be willing to pay more for the extra complexity and it would also skyrocket job security.

How would multi-hop routing work for ~100M domains, anyway? Requiring a hop in the middle could be useful in order to create a choke point where rate limiting can be done, but doing multihop makes little sense. The authorization information implied in the routing can just as easily be learned from the sender, if protected through cryptographic means. (Yes, #include <pki.h> but that's the part where we show that we aren't so lazy after all.)

On 14-apr-04, at 1:56, John Curran wrote:

...

This approach has two main advantages over filtering port 25:

...

1. People can still talk to unlisted SMTP hosts if they feel they have a good reason to do so (ie, I get >to deliver messages directly to my server from home rather than being forced to use my service

...

provider's which may or may not work)

You're right... Rather than simply having you tell your provider that you're responsible and having port 25 outward opened up, the freedom for anyone to send to port 25 on an ad-hoc basis like we have today is a better idea. Today's spam isn't a problem; everything's working as designed.

I understand your frustration, but the approach of blocking port 25 isn't the right one. It may be convenient for you, but there are plenty of people who have good reasons for using other SMTP servers than their access provider's ones. And do you think people who are unable to run a good mail service will be able to selectively open up filters in a sane way? Filtering can also have a serious performance impact on some equipment. And of course this approach isn't going to work anyway: many access providers can't even be bothered to implement anti-spoofing filters, so there is no way that ALL consumer access providers are going to do this within a reasonable time frame.

...

The good news is that the IETF is now starting work on this, so expect results in two or three years.

Great idea: here's a case where we need less connectivity and better operational practices, but rather than take that task on, we should do more protocol work.

The idea is that new records in the DNS show which hosts are allowed to deliver mail for a domain. This means spammers must use a domain they control. That's a good start, as it makes white- and blacklisting a lot easier. However, this isn't enough. A next step would be to require that a host that is delivering mail must be flagged as a designated outgoing SMTP host for the reversed mapping domain name of its IP address. (Which obviously isn't going to happen for Joe Cable or Jane ADSL.) (There is still an issue with IPv6 though, as here everyone, including consumers, usually runs their own reverse DNS servers.)

The reality is that the vast majority of email is handed off to a designated mail relay (whether we're talking about consumer connections or office environments), and if we actually configured connectivity in this matter, there wouldn't be a problem.

I don't think cutting off one of the monster's heads will do it (there was spam in the good old days when Windows didn't do IP without installing Trumpet Winsock or something similar). There are other ways to get rid of almost all spam, but apparently for most people the pain isn't bad enough to start using them yet. (I installed Spamassasin over the weekend, and it caught 50 of 53 overnight spam messages. My client caught the remaining 3, no false positives.)

On 14 Apr 2004, at 04:00, Andrew - Supernews wrote:

Iljitsch> It may be convenient for you, but there are plenty of Iljitsch> people who have good reasons for using other SMTP servers Iljitsch> than their access provider's ones.

For these people there is port 587.

For some of these people there is also (apparently!) MAPI over HTTPS. Joe

On 14-apr-04, at 17:45, JC Dill wrote:

...

I understand your frustration, but the approach of blocking port 25 isn't the right one. It may be convenient for you, but ...

Dood, this *exact* argument was made ~10 years ago against closing open relays. So, do you think that everyone should just open their servers to relaying for anyone, since closing all the open relays has proven to be inconvenient for some, and not a 100% effective solution?

Hm... "If you go faster than 30 km/h in a train the air will be sucked out and everyone inside will suffocate" vs "if you fly through the stratosphere in an airplane without a closed cabin the air will be sucked out and everyone inside will suffocate". So just because the former turned out incorrect the latter is as well? Now one could view a typical Windows box behind a broadband connection to be functionally equivalent to an open relay, in which case "closing the relay" would make sense, as open relays allow malicious third parties to unload their garbage upon the net with little recourse. However, filtering TCP port 25 is bad not just because it is massively inconvenient for many people (ever work in support?) but also because this is fixing an application layer problem at the transport layer, which is bad both architecturally and performance wise. (And yes, all those CPU or ASIC cycles inspecting every single packet, including the 99% that aren't email in the first place, cost real power that causes real CO2 to be released into the atmosphere, etc...) If despite this, filtering port 25 would actually have a decent chance of helping us get rid of spam, maybe, just maybe we should consider it. But as I've said before: spam was there when Windows was too stupid to even be vulnerable to anything coming in from the net, and the likeliness of global cooperation within a reasonable timeframe is close to zero anyway.

p.s. Please do not cc me on replies to the list. Please reply to the list only, or to me only (as you prefer) but not to both.

Maybe the list should add a reply-to? Or am I starting another flamewar here?

...

flamewar here?

No, it goes with the subject, lazy people run systems which don´t check if they got the same message twice.

I like the reply-to-all.. when the list is busy its easier to spot replies to my post if i'm choosing to ignore new threads.. :) Steve

On 14-apr-04, at 21:16, JC Dill wrote:

...

However, filtering TCP port 25 is bad not just because it is massively inconvenient for many people (ever work in support?)

Simply put, I do not agree with your assertion here.

And you conveniently left out all the more important ones again. I guess you must be right then.

We need to stop whining that it's "hard" or "expensive" do to the right thing and close loopholes that are abused by spammers. It's much harder and more expensive long term to NOT do the right thing.

Ok, speaking as someone who operates networks right now (I only run a mail server for one user: myself): if you application types can't make your protocols and implementations do what you want: tough. That's your problem. I'm not about to change the network to accommodate you. There are (potentially) 255 other protocols in IP and 65535 other ports in TCP, what if they all want special handling? Forget it. But feel free to come back and complain again when the percentage of network traffic for your protocol reaches double digits.

On (13/04/04 15:52), John Curran wrote:

I'm very much suggesting blocking outward to the Internet port 25 traffic, except from configured mail relays for that end-user site. Those hosts which have MSTP malware are stopped cold as a result.

so the malware writers start using port 80 through open proxies...they do already. or they go after the im client ports more. there are ways to send mail if 25 is blocked to me /joshua -- When in danger, or in doubt, run in circles, scream and shout. - unknown -

so the malware writers start using port 80 through open proxies...they do already. or they go after the im client ports more. there are ways to send mail if 25 is blocked to me

But if the email architecture has been changed to only allow known users to inject email into it, then other service architectures will have that as an example to follow. The fact that a particular solution will not lead directly to world peace is not sufficient reason for discarding that solution. Michael Dillon

On Wed, 14 Apr 2004 Michael.Dillon@radianz.com wrote:

...

Paul, let me add one more to your list: As a community, we have been too lazy to take hold of the architectural source of the problem, which is the complete lack of accountability over the ability to post email.

Hear, hear.

...

Of course, this breaks the end-to-end model of the Internet... Too bad. End-to-end makes sense in some contexts, and it doesn't in others. This is the latter case.

John, I don't believe that it is necessary to break the end-to-end model of the Internet in order to implement accountability for posting email. Rather than filtering port 25 at the user ISP, every ISP who operates an SMTP server could simply get off their butt and stop accepting connections from anyone that they don't know. In the case of a user ISP, they know all their own customers. And they should know a significant number of their email peers. If people can make arrangments for NNTP peering or BGP peering rather than opening it to all comers, why can't we do the same for SMTP? Pure laziness and lack of vision, IMHO.

A lack of desire to further commercialize something we all pay for already? after smtp peering comes smtp de-peering, settlement based smtp exchange and smtp transit, etc.

Michael Dillon

-- -------------------------------------------------------------------------- Joel Jaeggli Unix Consulting joelja@darkwing.uoregon.edu GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2

On 15-apr-04, at 2:45, Paul Vixie wrote:

preventing DDoS and IP source address forgery each also break what the IAB calls "the end-to-end model".

How so?

(dunno if you heard, but in spite of 128 bits of address space, the enterprise user community is now asking for IPv6 NAT.)

I hadn't, pointer please?