Re: The End-To-End Internet (was Re: Blocking MX query)
On 9/6/12, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: Owen DeLong wrote: You're demanding an awful lot of changes to the entire internet to All that necessary is local changes on end systems of those who want the end to end transparency. Achieving end to end, and breaking interoperability while introducing a level of complexity and points of failure that noone will accept, is no good. I refer you back to RFC1925 number (6). If you had to modify the implementation on endpoints that want to communicate end-to-end, then by definition you don't have transparency. The inability to communicate end-to-end with unmodified endpoints makes it non-transparent, and is itself a break of the principle. UPnP is not robust enough either for the suggested application. The RFC3102 you mention doesn't have acceptance; the concept of RSIP was not proven tenable, that it actually works or scales and can be implemented reliably with real applications on real networks in the first place. Achieving true 'end to end' with such a scheme would require alterations to many protocol standards which didn't happen, and there would be many interoperability breaks. There is no changes on the Internet. Masataka Ohta -- -JH
Re: The End-To-End Internet (was Re: Blocking MX query)
On 9/6/12 8:27 PM, Owen DeLong wrote: Despite my scepticism of the overall project, I find the above claim a little hard to accept. RFC 2052, which defined SRV in an experiment, came out in 1996. SRV was moved to the standards track in 2000. I've never heard an argument why it won't work, and we know that SRV records are sometimes in use. Why couldn't that mechanism be used more widely? If browsers started implementing it, it could. This is currently being discussed in the httpbis working group as part of the http 2.0 discussion. Also, I'll note that at least one browser has implemented XMPP without the mandatory SRV record, and it's next to useless for XMPP (in fact it seems to only work with a handful of broken XMPP implementations), so look for SRV in at least one browser in the next year or so, I'd guess. I suppose the more accurate/detailed statement would be: Without modifying every client on the internet, there is no way for the clients trying to reach you to reliably be informed of this port number situation. If you're going to touch every client, it's easier to just do IPv6. Well, this depends on who you think you is. The browser gang regularly touches many MANY (but not all) clients. Eliot
Re: The End-To-End Internet (was Re: Blocking MX query)
Well, this depends on who you think you is. The browser gang regularly touches many MANY (but not all) clients. Not everything on the internet is accessed using a browser. Is adding SRV to browsers a good thing? Yes. Is end-to-end transparent addressing a good thing? Yes. Does one have anything to do with the other? Only in the delusional mind of Masataka. Real transparent addressing will come with IPv6. IPv4 does not scale. It's time to move forward. Owen
Re: The End-To-End Internet (was Re: Blocking MX query)
Eliot Lear wrote: On 9/6/12 8:27 PM, Owen DeLong wrote: If you're going to touch every client, it's easier to just do IPv6. Well, this depends on who you think you is. The browser gang regularly touches many MANY (but not all) clients. Though I merely stated: The easiest part of the deployment is to modify end systems. according to Owen's delusion confirmed by private communications (I can't understand why he can do it public), client, seemingly, also means middle NAT boxes, even though they are still fine as long as they are clients or servers supporting UPnP. Yes, the easiest part of the deployment is to modify end systems, to modify protocol stacks and browsers of the end systems. Masataka Ohta
Re: The End-To-End Internet (was Re: Blocking MX query)
On Tue, 11 Sep 2012 05:51:53 +0900, Masataka Ohta said: Anything written in RFC1796 should be ignored, because RFC1796, an informational, not standard track, RFC, states so. On the other hand, if you're relying on the fact that 1796 is informational in order to ignore it, then you're following its guidance even though it's not a standard. Insisting on being pedantic on its status will merely leave you wondering who shaves the barber. Or, is it time to retract your silliness? Standard or not, we have Christian Huitema, John Postel, and Steve Crocker telling you something about RFCs and how they actually work. Which is more likely, that all 3 of them were wrong, or that you're the one that's confused? pgpT9gZIi3XWV.pgp Description: PGP signature
Re: The End-To-End Internet (was Re: Blocking MX query)
(2012/09/11 20:52), valdis.kletni...@vt.edu wrote: On Tue, 11 Sep 2012 05:51:53 +0900, Masataka Ohta said: Anything written in RFC1796 should be ignored, because RFC1796, an informational, not standard track, RFC, states so. On the other hand, if you're relying on the fact that 1796 is informational No, I don't. It's Jimmy, Eliot and you who are relying on a non standard track RFC to deny RFC3102 and all the non standard track RFCs, which is the silly paradox. Standard or not, we have Christian Huitema, John Postel, and Steve Crocker If you have some respect to them, don't involve them with your silly paradox. Masataka Ohta
Re: The End-To-End Internet (was Re: Blocking MX query)
On 9/11/12, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: (2012/09/11 20:52), valdis.kletni...@vt.edu wrote: On Tue, 11 Sep 2012 05:51:53 +0900, Masataka Ohta said: No, I don't. It's Jimmy, Eliot and you who are relying on a non standard track RFC to deny RFC3102 and all the non standard track RFCs, which is the silly paradox. Straw man. We don't rely on a non standard track RFC to deny rfc3102 having significance, furthermore, we don't indicate that all non standard track RFCs are of no significance; he's just being nice about it. The rfc1796 just happens to contain a useful explanation. If you don't read 3102 selectively, ignoring the disclaimers, you can very easily see that RSIP is not considered a viable standard in its present form, but possibly someone /might/ find it suitable for experimental use. RFC3102 denies itself, and please read the IESG note at the top of the document; where fundamental problems are admitted to with regards to interoperability and transparency. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Which means that RSIP has not received technical review or acceptance like standards have. The protocol doesn't have to work for an Experimental or Informational RFC to be published. The non-standards track rfc might still contain useful information, but 3102 is a little more authoritative than someone's blog entry. There are other non-standards track RFCs that are more important, take RFC 1149 for example Just being a RFC alone doesn't make a document important or not, reliable or not, anymore than a news article is important or not just because it appeared on a certain bulletin board. For now, and in its current form, I will discount the relevance or usefulness of the experimental protocol described in rc3102. Standard or not, we have Christian Huitema, John Postel, and Steve Crocker If you have some respect to them, don't involve them with your silly paradox. -- -JH
Re: The End-To-End Internet (was Re: Blocking MX query)
On 09/09/2012 23:24, Masataka Ohta wrote: Oliver wrote: Just because something is documented in RFC does not automatically make it a standard, nor does it necessarily make anyone care. That's not a valid argument against text in the RFC proof read by the RFC editor as the evidence of established terminology of the Internet community. you may want to read rfc 1796, and then retract what you said because it sounds silly. Nick
Re: The End-To-End Internet (was Re: Blocking MX query)
Nick Hilliard wrote: Just because something is documented in RFC does not automatically make it a standard, nor does it necessarily make anyone care. That's not a valid argument against text in the RFC proof read by the RFC editor as the evidence of established terminology of the Internet community. you may want to read rfc 1796, and then retract what you said because it sounds silly. Anything written in RFC1796 should be ignored, because RFC1796, an informational, not standard track, RFC, states so. Or, is it time to retract your silliness? Masataka Ohta
Re: The End-To-End Internet (was Re: Blocking MX query)
On Sun, Sep 9, 2012 at 6:24 PM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: Oliver wrote: You're basically redefining the term end-to-end transparency to suit your own Already in RFC3102, which restrict port number ranges, it is stated that: This document examines the general framework of Realm Specific IP (RSIP). RSIP is intended as a alternative to NAT in which the end- to-end integrity of packets is maintained. We focus on implementation issues, deployment scenarios, and interaction with other layer-three protocols. Just because something is documented in RFC does not automatically make it a standard, nor does it necessarily make anyone care. That's not a valid argument against text in the RFC proof read by the RFC editor as the evidence of established terminology of the Internet community. In case Nick's comment wasn't obvious enough: RFC 1796: Not All RFCs Are Standards It is a regrettably well spread misconception that publication as an RFC provides some level of recognition. It does not, or at least not any more than the publication in a regular journal. RFC 3102: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. As to your original point that software could be constructed that restores end-to-end through a NAT device by some kind of dynamic but published assignment of incoming ports to specific hosts behind the NAT... that's not really true. End-to-end is generally described as a layer 3 phenomenon. Dinking around with ports means you're at layer 4. Which means that only specific pre-programmed transports can pass even it you would like all protocols to be able to. There is another technology, also called NAT and described in RFC 1631, which translates layer 3 addresses 1:1, exactly one address inside for one address outside. While it's possible to talk about end-to-end with that technology, we are for practical, operational purposes just shy of -never- talking about or using that kind of NAT. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: The End-To-End Internet (was Re: Blocking MX query)
William Herrin wrote: In case Nick's comment wasn't obvious enough: Anything written in RFC1796 should be ignored, because RFC1796, an informational, not standard track, RFC, states so. It's so obvious. RFC 1796: It is a regrettably well spread misconception that publication as an RFC provides some level of recognition. It does not, or at least not any more than the publication in a regular journal. Your silliness, too, is appreciated. End-to-end is generally described as a layer 3 phenomenon. Read the original paper on it: http://groups.csail.mit.edu/ana/Publications/PubPDFs/End-to-End%20Arguments%20in%20System%20Design.pdf to find that the major example of the paper is file transfer, an application. we are for practical, operational purposes just shy of -never- talking about or using that kind of NAT. For practical operational purposes, it is enough that PORT command of ftp works transparently. Masataka Ohta
Re: The End-To-End Internet (was Re: Blocking MX query)
Oliver wrote: You're basically redefining the term end-to-end transparency to suit your own Already in RFC3102, which restrict port number ranges, it is stated that: This document examines the general framework of Realm Specific IP (RSIP). RSIP is intended as a alternative to NAT in which the end- to-end integrity of packets is maintained. We focus on implementation issues, deployment scenarios, and interaction with other layer-three protocols. Just because something is documented in RFC does not automatically make it a standard, nor does it necessarily make anyone care. That's not a valid argument against text in the RFC proof read by the RFC editor as the evidence of established terminology of the Internet community. It's you who tries to change the meaning of end to end transparency. Denial: not just a river in Egypt. Invalid denial. Masataka Ohta
Re: The End-To-End Internet (was Re: Blocking MX query)
On Wed, Sep 05, 2012 at 02:15:07PM -0700, Joe St Sauver wrote: 2) The Spamhaus CBL tracks the level of bot spam currently seen, including breaking out statistics by a number of factors. 3) Currently, the US, where port 25 filtering is routinely deployed by most large ISPs, is ranked 158th among countries when you consider botted users on a per capita basis: http://cbl.abuseat.org/countrypercapita.html 4) While that's not perfect (after all, there are still at least 133,811 listings for the US), on a PER-CAPITA basis, it's not bad -- that's just ~0.055% of US Internet users that are infected, relative to some countries where the rate of detected infection (based on spam emission) may be 4 to 5% or more. I don't believe those numbers say that last. I *wish* those numbers said that, but I don't think they do. Here's why. A. bot spam seen (by whatever number of sensors are deployed) is conditional on bot spam making it out of its local network and onto some other network where is sensor exists. Clearly, port 25 blocking will dramatically curtail that. Thus, spam is still being generated by those systems: it's just not getting anywhere. B. Spam is not the only form of abuse generated by bots. Some participate in DDoS attacks, some host illicit web sites, some harvest addresses, the list is endless. Any sensor which only looks for spam arriving via SMTP on port 25 will miss all those. C. Some bots engage in secondary support activities (e.g., hosting DNS for spammer domains) which is not intrinsicly abusive, but is certainly abusive in context. Most of this will be missed by most of everything and everyone. D. Some bots do nothing -- that is, nothing overtly recognizable by external sensors of any kind at any location. They're either harvesting local data or perhaps they're simply being held in reserve, a practice our adversaries adopted quite early on. Thus we can't use anybody's numbers for observed bot-generated spam to estimate infection rates -- other than to set a lower bound on them. The upper bound can be, and like likely is, MUCH higher. Doubly so because there is abolutely no reason of any kind to think that infection rates of US-based hosts significantly differ from global norms. More broadly, the per-nation rates are interesting but probably unimportant: this is a global problem, so even if country X solved it (for a useful value of solved) it would matter little. I think at this point any estimate of bot population under 200M should be laughed out of the room, and that (just as it has for a decade) it continues to monotonically increase. ---rsk
Re: The End-To-End Internet (was Re: Blocking MX query)
In message 108454.1346989...@turing-police.cc.vt.edu, valdis.kletni...@vt.edu writes: --==_Exmh_1346989445_1993P Content-Type: text/plain; charset=us-ascii On Fri, 07 Sep 2012 08:30:12 +1000, Mark Andrews said: In message 85250.1346959...@turing-police.cc.vt.edu, valdis.kletni...@vt.edu writes: My PS3 may want to talk to the world, but I have no control over Comcast's DNS. What point are you trying to make? Comcast's servers support SRV as do all general purpose name servers. For HTTP at least you need to be backwards compatible so there is no reason not to add SRV support. Sure, Comcast's servers will happily support an SRV entry for my PS3. However, Comcast's business processes don't support a way for me to request said SRV record be listed. Heck, I don't even get a static IP with my current service package. ;) There are plenty of companies that will serve whatever you want them to serve. Now *I* have the technical chops to talk to the guys at dyndns.org or other providers and get an SRV entry created under some domain name pointing back at my IP address. However, Joe Sixpack doesn't really have that option. And unless you figure out a scalable and universal way for Joe Sixpack's Xbox or PS3 or whatever to request an SRV entry saying that the PS3 wants to do service foobar on port 34823, you can't use SRV like that. There is NOTHING stopping Sony adding code to the PS3 to perform dynamic updates to add the records. We have a well established protocol to do this securely. 100's of millions of records get updated daily using this protocol in the corporate environment. This is NOTHING Joe Sixpack can't do with a smidgen of help on behalf of product vendors. Home router vendors already have code to do this. domain name for the PS account name password account name and password form the TSIG information to secure the dynamic update. A better proposal would probably be having the NAT itself run a 'portmap' type service on a well known port like 111. Except that still doesn't do a very good job of disambiguating two instances of foobar behind a NAT... -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: The End-To-End Internet (was Re: Blocking MX query)
Oliver wrote: All that necessary is local changes on end systems of those who want the end to end transparency. There is no changes on the Internet. You're basically redefining the term end-to-end transparency to suit your own Already in RFC3102, which restrict port number ranges, it is stated that: This document examines the general framework of Realm Specific IP (RSIP). RSIP is intended as a alternative to NAT in which the end- to-end integrity of packets is maintained. We focus on implementation issues, deployment scenarios, and interaction with other layer-three protocols. It's you who tries to change the meaning of end to end transparency. Masataka Ohta
Re: The End-To-End Internet (was Re: Blocking MX query)
Andrew Sullivan wrote: the DNS and won't discover anything about the DNS that can't be had via getaddrinfo() until long after its too late redefine the protocol in terms of seeking SRV records. Oh, sure, I get that. One of the problems I've had with the end to end NAT argument is exactly that I can't see how it's any more deployable than IPv6, for exactly this reason. The easiest part of the deployment is to modify end systems. Because of the 20-year problem, I think now would be an excellent time to start thinking about how to make usable all those nice features we already have in the DNS. Apple did it. See RFC6281. Masataka Ohta
Re: The End-To-End Internet (was Re: Blocking MX query)
On Sep 6, 2012, at 22:31 , Sean Harlow s...@seanharlow.info wrote: On Sep 6, 2012, at 23:44, valdis.kletni...@vt.edu wrote: However, Joe Sixpack doesn't really have that option. And unless you figure out a scalable and universal way for Joe Sixpack's Xbox or PS3 or whatever to request an SRV entry saying that the PS3 wants to do service foobar on port 34823, you can't use SRV like that. I think you missed the point on this one. Even if your PS3 has a public IP with no limitations on ports, how exactly are others going to find it to connect to it? I see three options here: 1. You have to give them the IP address, in which case it's not exactly rocket science to give them the port as well. The same Joe Sixpack who couldn't find the port couldn't likely figure out his IP either, so the PS3 would have to be able to identify its own public-facing IP and tell him, in which case it could also tell him the port. 2. DNS, which while many don't have this ability any that do should have no problem setting a SRV record. Obviously not all clients support the use of SRV records, but that's not the subject of this particular tangent. Anyone can set up free DNS from a variety of providers and get a domain name for ~$10/year. I'm not sure why you think there is anyone who can't get DNS. If you can operate a web browser and come up with $10/year or so, you can have forward DNS. The inability to influence Comcast's nameservers would only affect reverse lookups (which SRV goes forward, not reverse IIRC). 3. Intermediary directory server hosted at a known location. Pretty much the standard solution for actual PS3 titles as well as almost all other games since the late '90s. Rather than telling the user, the PS3 tells the central server its IP and port plus any useful metadata about the service being offered and the user just needs to give his friend a name or other identifier to find it in the list. Which becomes ugly and unnecessary with full transparency and useful DNS, which we get with IPv6 even without SRV records. To make SRV records meaningful, OTOH, virtually every client needs an update. None of these options are impacted by being behind a NAT as long as they have the ability to open a port via UPnP or equivalent, so if in an ideal world all client software understood SRV records this particular negative of NAT would be of minimal impact. Of course the real world is nowhere close to ideal and personally SIP phones and Jabber clients are the only things I've ever observed widely using SRV records, so at least for now I can't just do something like _http._tcp.seanharlow.info 86400 IN SRV 0 5 8080 my.home.fake. and host my personal site on my home server (Mozilla has had a bug open on this for over ten years, Chrome for three, and Webkit closed their bug as WONTFIX two years ago so I don't expect this to change any time soon). At this point we're coming back around to the already raised point about if we're going to have to change a lot of things, why not just put that effort in to doing it right with IPv6 rather than trying to keep address conservation via DNAT alive? +1 -- Address transparency is a good thing. Owen
Re: The End-To-End Internet (was Re: Blocking MX query)
This has been experimental with no forward progress since 2001. Any sane person would conclude that the experiment failed to garner any meaningful support. Is there any continuing active work on this experiment? Any running code? Didn't think so. Owen On Sep 6, 2012, at 23:23 , Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: Oliver wrote: All that necessary is local changes on end systems of those who want the end to end transparency. There is no changes on the Internet. You're basically redefining the term end-to-end transparency to suit your own Already in RFC3102, which restrict port number ranges, it is stated that: This document examines the general framework of Realm Specific IP (RSIP). RSIP is intended as a alternative to NAT in which the end- to-end integrity of packets is maintained. We focus on implementation issues, deployment scenarios, and interaction with other layer-three protocols. It's you who tries to change the meaning of end to end transparency. Masataka Ohta
Re: The End-To-End Internet (was Re: Blocking MX query)
Sean Harlow wrote: None of these options are impacted by being behind a NAT as long as they have the ability to open a port via UPnP or equivalent, so if in an ideal world all client software understood SRV records this particular negative of NAT would be of minimal impact. My point is that the impact can be minimized if 1) a set of port numbers is statically allocated to a host behind NAT without UPnP or PCP, just as allocating a static address to a host, which means there is no security concern w.r.t. dynamic assignment. Dynamic DNS update is not necessary, either. UPnP or PCP can still be used to collect information for reverse translation. 2) reverse translation can be performed by network and/or transport layer without involving applications, which makes modifications to application programs completely unnecessary. I have already confirmed that ftp PORT command work transparently. Of course the real world is nowhere close to ideal and personally SIP phones and Jabber clients are the only things I've ever observed widely using SRV records, As we can explicitly specify port numbers in URLs, support for SRV is not very essential. But, SRV will be more commonly used as PCP will be deployed. Masataka Ohta
Re: The End-To-End Internet (was Re: Blocking MX query)
Owen DeLong wrote: Then why is IPv6 deployment happening faster in the internet core than at the edge? The real world seems to defy your claims. Which world, are you talking about? Martian? This has been experimental with no forward progress since 2001. Obviously because it is a new protocol requiring new gateways, which is not the case with UPnP capable NAT. Moreover, it has nothing to do with the definition of the end to end transparency. Masataka Ohta
Re: The End-To-End Internet (was Re: Blocking MX query)
On Fri, 07 Sep 2012 16:01:10 +1000, Mark Andrews said: There is NOTHING stopping Sony adding code to the PS3 to perform dynamic updates to add the records. We have a well established protocol to do this securely. 100's of millions of records get updated daily using this protocol in the corporate environment. This is NOTHING Joe Sixpack can't do with a smidgen of help on behalf of product vendors. Home router vendors already have code to do this. domain name for the PS account name password account name and password form the TSIG information to secure the dynamic update. And my point was merely that you can't actually use SRV for this use case until the above is actually deployed, rather than in the nothing stopping SONY hand-waving state. pgp2oiZkBXqDM.pgp Description: PGP signature
Re: The End-To-End Internet (was Re: Blocking MX query)
On Friday 07 September 2012 15:23:30 Masataka Ohta wrote: Oliver wrote: All that necessary is local changes on end systems of those who want the end to end transparency. There is no changes on the Internet. You're basically redefining the term end-to-end transparency to suit your own Already in RFC3102, which restrict port number ranges, it is stated that: This document examines the general framework of Realm Specific IP (RSIP). RSIP is intended as a alternative to NAT in which the end- to-end integrity of packets is maintained. We focus on implementation issues, deployment scenarios, and interaction with other layer-three protocols. Just because something is documented in RFC does not automatically make it a standard, nor does it necessarily make anyone care. I refer you to RFC1149. Although, since you have such a hard-on for RFCs, you should check out RFC2460 - unlike 3102, it's standards-track and quite widely implemented. It's you who tries to change the meaning of end to end transparency. Denial: not just a river in Egypt. If the best rebuttal you can come up with is an experimental, unused RFC and a one-liner that basically amounts to NO U, I suggest you do everyone a favour and crawl back into the hole you came from. I realise that it must be a difficult and slow process coming to the realisation that everything you've advocated for and espoused is unmitigated garbage, but whilst you deal with that internal struggle, please save the rest of us from having to waste our time deconstructing the last vestiges of your folly. Regards, Oliver
Re: The End-To-End Internet (was Re: Blocking MX query)
On Tue, Sep 4, 2012 at 3:45 PM, William Herrin b...@herrin.us wrote: On Tue, Sep 4, 2012 at 2:22 PM, Jay Ashworth j...@baylink.com wrote: It is regularly alleged, on this mailing list, that NAT is bad *because it violates the end-to-end principle of the Internet*, where each host is a full-fledged host, able to connect to any other host to perform transactions. That's what firewalls *are for* Jay. They intentionally break end-to-end for communications classified by the network owner as undesirable. Whether a particular firewall employs NAT or not is largely beside the point here. Either way, the firewall is *supposed* to break some of the end to end communication paths. Exactly - talking about a *(subtle?)* difference here. 1) Breaking the E2E model because your security policy (effectively) dictates it. For the record, this is fine as it is your decision for your network. 2) Being forced to break that model by deficiencies in the underlying protocol/address-family. This is, shall we say, sub-optimal. /TJ
Re: The End-To-End Internet (was Re: Blocking MX query)
Subject: Re: The End-To-End Internet (was Re: Blocking MX query) Date: Wed, Sep 05, 2012 at 06:56:36PM -0400 Quoting William Herrin (b...@herrin.us): Thing is, spam levels *are* down a good 20% in the last couple years, that being about the time ISPs began doing this. More, 20% *is* in rough proportion the impacted customer counts on the handful of cable and DSL providers that implemented it. Not here. My experience is that it is at best static, but most likely increasing. Around here, the sad default is that it is impossible to buy tcp/25 access except in colos and over tunnels. It does not help. It just is a very bad precedent, it looks like you are doing something. Which for lawyers is just as fine as efficient action. We need to remind ourselves that this Internet thing got big simply because it let people have computers send packets directly to other peoples computers. There was this guy called Aesop who wrote a story about blocking traffic on the Internet, but since the Internet wasn't known at the time (too secret) he had to rephrase it so it became a story about a goose that lays golden eggs. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I HAVE to buy a new DODGE MISER and two dozen JORDACHE JEANS because my viewscreen is USER-FRIENDLY!! signature.asc Description: Digital signature
Re: The End-To-End Internet (was Re: Blocking MX query)
My idealistic preference would be the ISP allows outbound port 25, but are highly responsive to abuse complaints; My idealistic preference is that ISPs not let their botted customers fill everyone's inbox with garbage. Why do you think that blocking port 25 precludes logging what they block, and dealing with customers whose traffic shows that they're botted? R's, John
Re: The End-To-End Internet (was Re: Blocking MX query)
On Thursday 06 September 2012 14:01:50 Masataka Ohta wrote: All that necessary is local changes on end systems of those who want the end to end transparency. There is no changes on the Internet. You're basically redefining the term end-to-end transparency to suit your own agenda. Globally implementing what is basically an application layer protocol in order to facilitate the functioning of an upper layer protocol (i.e. IPv4) is patent nonsense. The purpose of each layer is to facilitate the one it encapsulates, not the other way around. What you advocate is not end-to-end transparency but point-to-point opacity hinging on a morass of hacks that constitute little more than an abuse of existing technologies in an attempt to fulfil an unscalable goal. Fortunately, it is exactly that fact which makes all of your drafts and belligerent evangelising utterly pointless; you can continue to make noise and attempt to argue by redefinition all you like, the world will continue to forge ahead with the deployment of IPv6 and the *actual* meaning of the end-to-end principle will remain as it is. Regards, Oliver
Re: The End-To-End Internet (was Re: Blocking MX query)
On Wed, Sep 05, 2012 at 09:39:44PM -0700, Owen DeLong wrote: Never mind the fact that all the hosts trying to reach you have no way to know what port to use. Despite my scepticism of the overall project, I find the above claim a little hard to accept. RFC 2052, which defined SRV in an experiment, came out in 1996. SRV was moved to the standards track in 2000. I've never heard an argument why it won't work, and we know that SRV records are sometimes in use. Why couldn't that mechanism be used more widely? Best, A -- Andrew Sullivan Dyn Labs asulli...@dyn.com
Re: The End-To-End Internet (was Re: Blocking MX query)
On Thu, Sep 6, 2012 at 11:14 AM, Andrew Sullivan asulli...@dyn.com wrote: RFC 2052, which defined SRV in an experiment, came out in 1996. SRV was moved to the standards track in 2000. I've never heard an argument why it won't work, and we know that SRV records are sometimes in use. Why couldn't that mechanism be used more widely? Hi Andrew, Because the developer of the next killer app knows exactly squat about the DNS and won't discover anything about the DNS that can't be had via getaddrinfo() until long after its too late redefine the protocol in terms of seeking SRV records. Leaving SRV out of getaddrinfo() means that SRVs will be no more than lightly used for the duration of the current networking API. The last iteration of the API survived around 20 years of mainstream use so this one probably has another 15 to go. Also there are efficiency issues associated with seeking SRVs first and then addresses, the same kind of efficiency issues with reverse lookups that lead high volume software like web servers to not do reverse lookups. But those pale in comparison to the first problem. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: The End-To-End Internet (was Re: Blocking MX query)
On Thu, Sep 06, 2012 at 01:49:06PM -0400, William Herrin wrote: the DNS and won't discover anything about the DNS that can't be had via getaddrinfo() until long after its too late redefine the protocol in terms of seeking SRV records. Oh, sure, I get that. One of the problems I've had with the end to end NAT argument is exactly that I can't see how it's any more deployable than IPv6, for exactly this reason. But the claim upthread was (I thought) that the application _can't_ know about this stuff, not that it's hard today. Because of the 20-year problem, I think now would be an excellent time to start thinking about how to make usable all those nice features we already have in the DNS. Maybe by the time I die, we'll have a useful system! Best, Andrew living in constant, foolish, failed hope Sullivan -- Andrew Sullivan Dyn Labs asulli...@dyn.com
Re: The End-To-End Internet (was Re: Blocking MX query)
On Sep 6, 2012, at 08:14 , Andrew Sullivan asulli...@dyn.com wrote: On Wed, Sep 05, 2012 at 09:39:44PM -0700, Owen DeLong wrote: Never mind the fact that all the hosts trying to reach you have no way to know what port to use. Despite my scepticism of the overall project, I find the above claim a little hard to accept. RFC 2052, which defined SRV in an experiment, came out in 1996. SRV was moved to the standards track in 2000. I've never heard an argument why it won't work, and we know that SRV records are sometimes in use. Why couldn't that mechanism be used more widely? If browsers started implementing it, it could. I suppose the more accurate/detailed statement would be: Without modifying every client on the internet, there is no way for the clients trying to reach you to reliably be informed of this port number situation. If you're going to touch every client, it's easier to just do IPv6. Owen
Re: The End-To-End Internet (was Re: Blocking MX query)
On Thu, 06 Sep 2012 11:14:58 -0400, Andrew Sullivan said: Despite my scepticism of the overall project, I find the above claim a little hard to accept. RFC 2052, which defined SRV in an experiment, came out in 1996. SRV was moved to the standards track in 2000. I've never heard an argument why it won't work, and we know that SRV records are sometimes in use. Why couldn't that mechanism be used more widely? My PS3 may want to talk to the world, but I have no control over Comcast's DNS. pgprKXFEYZ1RQ.pgp Description: PGP signature
Re: The End-To-End Internet (was Re: Blocking MX query)
It would be really nice if people making statements about the end to end principle would talk about the end to end principle. http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf The abstract of the paper states the principle: This paper presents a design principle that helps guide placement of functions among the modules of a distributed computer system. The principle, called the end-to-end argument, suggests that functions placed at low levels of a system may be redundant or of little value when compared with the cost of providing them at that low level. Examples discussed in the paper include bit error recovery, security using encryption, duplicate message suppression, recovery from system crashes, and delivery acknowledgement. Low level mechanisms to support these functions are justified only as performance enhancements. One of the authors of the paper has since restated it in a way that is significantly less useful, which is that the only place anything intelligent should be done in a network is in the end system. If you believe that argument, then WiFi networks should not retransmit lost packets (and as a result would become far less useful) and the Internet should not use routing protocols - it should only use source routing. So, yes, I think the Rise of the Stupid Network is a very interesting paper and site, but needs to be handled carefully. The argument argues for simplicity and transparency; when a function at a lower layer does something an upper layer - not just the application, but any respectively higher and lower layers - it can be difficult to debug the behavior. However, it is not a hard-and-fast the network should never do things that the end system doesn't expect; the paper makes it clear that there is a trade-off, and if the trade-off makes sense (retransmitting at the link layer in addition to the end to end retransmission in the case of WiFi) it doesn't preclude the behavior. It merely suggests that one think about such things (retransmitting in LAPB turned out to be a bad idea way back when). Complexities of various types are unavoidable; to quote a fourteenth century logician, a satisfactory syllogism contains no unnecessary complexity. Yes, I think that stateful network address translation violates the end to end principle. But it doesn't violate it because everyone can't talk with everyone directly; it violates it because a change is made in a packet that subverts an end system's intent and as a result randomly breaks things (for example, an ICMP packet-too-large response has to be specially handled by the NAT to make PMTU work). I would argue that a network-imposed policies like traffic filters violate the end to end principle no more than network-imposed routing (including not-routing) policies do. If you can't get somewhere or a given address isn't instantiated with a host, that's not particularly surprising. What might be surprising and difficult to diagnose would be something that sometimes allows packets through and sometimes doesn't without any clear reason. I suspect everyone on this list will agree that the KISS principle, aka end-to-end, is pretty important, and get irritated with vendors (cough) that push them towards complex solutions. A host directly sending mail to a remote MTA is not automatically a bad actor for any reason related to KISS. There are two issues, however, that you might think about. My employer tells me that they discard about 98% of email traffic headed to me; a study of my own email history says that the email from outside that passes that filter and which is what I expect to receive comes through less than 1000 immediate SMTP predecessors to the first Cisco MTA; running the same survey on my junk folder (which is only 30 days, not 18 years) has about 5000 SMTP predecessors, the 1000 and the 5000 are disjoint sets. So an SMTP connection to a remote MTA is not a bad thing automatically, but it raises security eyebrows - and should - because it is similar to how spam and other attacks are transmitted. In addition, at least historically, in many cases those MUAs directly connecting to remote MTAs try or tried to use them as open relays, and it was difficult for the relay to authenticate random systems. Having an MUA give its traffic to a first hop MTA using SSL or some other form of service authentication/authorization improves the security of the service. That can be overcome using S/MIME, of course, given a global PKI, but DKIM depends on the premise that the originator has somehow been authenticated and shown to be authorized to send email. On Sep 4, 2012, at 11:22 AM, Jay Ashworth wrote: - Original Message - From: Owen DeLong o...@delong.com I am confused... I don't understand your comment. It is regularly alleged, on this mailing list, that NAT is bad *because it violates the end-to-end principle of the Internet*,
Re: The End-To-End Internet (was Re: Blocking MX query)
In message 85250.1346959...@turing-police.cc.vt.edu, valdis.kletni...@vt.edu writes: --==_Exmh_1346959671_1993P Content-Type: text/plain; charset=us-ascii On Thu, 06 Sep 2012 11:14:58 -0400, Andrew Sullivan said: Despite my scepticism of the overall project, I find the above claim a little hard to accept. RFC 2052, which defined SRV in an experiment, came out in 1996. SRV was moved to the standards track in 2000. I've never heard an argument why it won't work, and we know that SRV records are sometimes in use. Why couldn't that mechanism be used more widely? My PS3 may want to talk to the world, but I have no control over Comcast's DNS. What point are you trying to make? Comcast's servers support SRV as do all general purpose name servers. For HTTP at least you need to be backwards compatible so there is no reason not to add SRV support. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Exmh version 2.5 07/13/2001 iQIVAwUBUEj5NwdmEQWDXROgAQL/fRAAjHmAtVBMjQAybs2TWrzWMcE6e9k6A7Av LvOXJAS1leKr0tyg0lG4+IwuMCN5bV3+V8F7+bWAfQFSBIj9aH5ymSuxdO/LJVoj TdPRSRzTcPCL0mmIB5LbBdrDgi/PcruLdGDgOiLiLPhUkXnRJ+OmzR2WmAh4jgOz dVLb0ugujqbmqm7tzgxeiC0yzF9EiL3RQAZwzZI9Tcbnh0rELMHWBhgGeIO5KbA9 4iCh79MkrPXr4uONVQrCmbNBuqcziGIekKDGCpSUqwynzbc7NK00+Xhhkz2inNOn m7v73JFKzLd3AAjBenv3Yqz9hIwUGT4D9kW6Kof5Ah5SmzLY1ZOKpi+08M6i6SS/ I54neNmQ7lLuO9p7EsGpRTfUN1MOMEYXo8yOFTNQI7FDWCXNhWz/MjE3wxmXQYeA jBd8EE7m0QGuM6l/AhaS9BRXdZUXn8KK5E4N5YubJonLIuTzkTXuHmhFOB3Khlrl rHfl84sf8TdeDuxlJZs4PLdfRJooknNjSqLYfyfH0UeK3mSjlY3rpjcAZbSZsMdy vUDO0hU1C6FNFCXdkwRVZUtHxFX+l1sOtk76bt4s7NiWhwwGxwrykvk66qPa3YsH nyIWS7SsX245hy7dayKMKpYIByaAO6E7uVWzhgOobRMe3omP911BE30D2KYLXFvn wVqujobWuC4= =o0nz -END PGP SIGNATURE- --==_Exmh_1346959671_1993P-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: The End-To-End Internet (was Re: Blocking MX query)
On Fri, 07 Sep 2012 08:30:12 +1000, Mark Andrews said: In message 85250.1346959...@turing-police.cc.vt.edu, valdis.kletni...@vt.edu writes: My PS3 may want to talk to the world, but I have no control over Comcast's DNS. What point are you trying to make? Comcast's servers support SRV as do all general purpose name servers. For HTTP at least you need to be backwards compatible so there is no reason not to add SRV support. Sure, Comcast's servers will happily support an SRV entry for my PS3. However, Comcast's business processes don't support a way for me to request said SRV record be listed. Heck, I don't even get a static IP with my current service package. ;) Now *I* have the technical chops to talk to the guys at dyndns.org or other providers and get an SRV entry created under some domain name pointing back at my IP address. However, Joe Sixpack doesn't really have that option. And unless you figure out a scalable and universal way for Joe Sixpack's Xbox or PS3 or whatever to request an SRV entry saying that the PS3 wants to do service foobar on port 34823, you can't use SRV like that. A better proposal would probably be having the NAT itself run a 'portmap' type service on a well known port like 111. Except that still doesn't do a very good job of disambiguating two instances of foobar behind a NAT... pgpAscas1weY8.pgp Description: PGP signature
Re: The End-To-End Internet (was Re: Blocking MX query)
On 09/04/2012 03:52 PM, Michael Thomas wrote: On 09/04/2012 09:34 AM, Daniel Taylor wrote: If you are sending direct SMTP on behalf of your domain from essentially random locations, how are we supposed to pick you out from spammers that do the same? Use DKIM. You say that like it's a lower bar than setting up a fixed SMTP server and using that. Besides, doesn't DKIM break on mailing lists? -- Daniel Taylor VP Operations Vocal Laboratories, Inc dtay...@vocalabs.com 952-941-6580x203
Re: The End-To-End Internet (was Re: Blocking MX query)
On 09/05/12 05:56 , Daniel Taylor wrote: Use DKIM. You say that like it's a lower bar than setting up a fixed SMTP server and using that. Besides, doesn't DKIM break on mailing lists? Not only that, but a majority of spam I receive lately has a valid DKIM signature. They are adaptive, like cockroaches.
Re: The End-To-End Internet (was Re: Blocking MX query)
On Wed, Sep 05, 2012 at 07:50:12AM -0700, Henry Stryker wrote: Not only that, but a majority of spam I receive lately has a valid DKIM signature. They are adaptive, like cockroaches. This is why tcp port 25 filtering is totally effective and will remain so forever. Definitely worth breaking basic function principles of a global communications network over which trillions of dollars of commerce occur. -- . ___ ___ . . ___ . \/ |\ |\ \ . _\_ /__ |-\ |-\ \__
Re: The End-To-End Internet (was Re: Blocking MX query)
On 09/05/2012 05:56 AM, Daniel Taylor wrote: On 09/04/2012 03:52 PM, Michael Thomas wrote: On 09/04/2012 09:34 AM, Daniel Taylor wrote: If you are sending direct SMTP on behalf of your domain from essentially random locations, how are we supposed to pick you out from spammers that do the same? Use DKIM. You say that like it's a lower bar than setting up a fixed SMTP server and using that. I say it like it addresses your concern. Mike
Re: The End-To-End Internet (was Re: Blocking MX query)
On Wed, Sep 5, 2012 at 11:11 AM, Izaac iz...@setec.org wrote: On Wed, Sep 05, 2012 at 07:50:12AM -0700, Henry Stryker wrote: Not only that, but a majority of spam I receive lately has a valid DKIM signature. They are adaptive, like cockroaches. This is why tcp port 25 filtering is totally effective and will remain so forever. Definitely worth breaking basic function principles of a global communications network over which trillions of dollars of commerce occur. -- . ___ ___ . . ___ . \/ |\ |\ \ . _\_ /__ |-\ |-\ \__ But as someone pointed out further back on this thread people who want to have their mail servers available to people who are on the other side of port 25 filtering just use the alternate ports. So then what does filtering port 25 accomplish? Greg
Re: The End-To-End Internet (was Re: Blocking MX query)
On Sep 5, 2012, at 11:11, Izaac wrote: This is why tcp port 25 filtering is totally effective and will remain so forever. Definitely worth breaking basic function principles of a global communications network over which trillions of dollars of commerce occur. Two things to note: 1. Restricting outbound port 25 is nothing new. It's been in use since before SPF or DKIM were under development, yet it hasn't been defeated/bypassed. Henry didn't specify whether the DKIM-valid messages he received were forged or if they just came from a random spam domain. If the latter, of course that's trivial for spammers to make appear legitimate because the only goal of such systems is to verify that the sender controls or is approved by the domain the message claims to be from. 2. The reason port 25 blocks remain effective is that there really isn't a bypass. If you want to spam, at some point you must establish a TCP connection to port 25 on the destination mail server. You can either do this from your own machines (where a good hosting provider will cut you off in a hurry) or by using someone else's illegitimately. Servers tend to be located in datacenters where again a good provider will take action, so botted end-user machines are obviously a huge thing to spammers. Eliminate the ability for the majority of those bots to make said port 25 connections, you've now forced them in to a much smaller operating area where they're more likely to be found. The only bypass is to go back to using their own machines or compromised equipment on higher-grade connections. --- Sean Harlow s...@seanharlow.info
Re: The End-To-End Internet (was Re: Blocking MX query)
On Sep 5, 2012, at 11:46, Greg Ihnen wrote: But as someone pointed out further back on this thread people who want to have their mail servers available to people who are on the other side of port 25 filtering just use the alternate ports. So then what does filtering port 25 accomplish? The alternate port 587 is for users of that mail server to send mail through it, presumably authenticated, not for receipt of random mail from the internet. This allows those users to relay email through their server unaffected while behind a port 25 block. Configuring it to accept all messages on that port would defeat the purpose. --- Sean Harlow s...@seanharlow.info
Re: The End-To-End Internet (was Re: Blocking MX query)
On 09/05/2012 07:50 AM, Henry Stryker wrote: Not only that, but a majority of spam I receive lately has a valid DKIM signature. They are adaptive, like cockroaches. The I part of DKIM is Identified. That's all it promises. It's a feature, not a bug, that spammers use it. Mike
Re: The End-To-End Internet (was Re: Blocking MX query)
On 09/05/2012 08:49 AM, Sean Harlow wrote: 2. The reason port 25 blocks remain effective is that there really isn't a bypass. In the Maginot Line sense, manifestly. Mike
Re: The End-To-End Internet (was Re: Blocking MX query)
On 09/05/12 09:13 , Michael Thomas wrote: The I part of DKIM is Identified. That's all it promises. It's a feature, not a bug, that spammers use it. Which is why DKIM does not really address any concerns. The spammers have reduced its value. I am retired now, but do run my own mail server from home. It is a challenge. Not all static IP's provided by ISP's are outside of home IP groups, so you will find some of them blocked at some large domains. SPF and DKIM do help, a bit. What I have found really makes the home MTA possible are 1. a real static IP 2. proper DNS (A and PTR; PTR must at least exist) 3. tuning your MTA to respect the restraints of various large ISP's Lacking 1 2, it is just not worth the effort attempting direct delivery, if you value actual delivery of your email. I would never even attempt such from a peripatetic laptop.
Re: The End-To-End Internet (was Re: Blocking MX query)
On 09/05/2012 10:19 AM, Michael Thomas wrote: On 09/05/2012 05:56 AM, Daniel Taylor wrote: On 09/04/2012 03:52 PM, Michael Thomas wrote: On 09/04/2012 09:34 AM, Daniel Taylor wrote: If you are sending direct SMTP on behalf of your domain from essentially random locations, how are we supposed to pick you out from spammers that do the same? Use DKIM. You say that like it's a lower bar than setting up a fixed SMTP server and using that. I say it like it addresses your concern. Well, if you've got proper forward and reverse DNS, and your portable SMTP server identifies itself properly, and you are using networks that don't filter outbound port 25, AND you have DKIM configured correctly and aren't using it for a situation for which it is inappropriate, then you'll get the same results with a portable SMTP server that you would sending through a properly configured static server. So, no, use DKIM does not address the delivery difficulties inherent to using a portable SMTP server. -- Daniel Taylor VP Operations Vocal Laboratories, Inc dtay...@vocalabs.com 952-941-6580x203
Re: The End-To-End Internet (was Re: Blocking MX query)
On 09/05/2012 12:50 PM, Daniel Taylor wrote: On 09/05/2012 10:19 AM, Michael Thomas wrote: On 09/05/2012 05:56 AM, Daniel Taylor wrote: On 09/04/2012 03:52 PM, Michael Thomas wrote: On 09/04/2012 09:34 AM, Daniel Taylor wrote: If you are sending direct SMTP on behalf of your domain from essentially random locations, how are we supposed to pick you out from spammers that do the same? Use DKIM. You say that like it's a lower bar than setting up a fixed SMTP server and using that. I say it like it addresses your concern. Well, if you've got proper forward and reverse DNS, and your portable SMTP server identifies itself properly, and you are using networks that don't filter outbound port 25, AND you have DKIM configured correctly and aren't using it for a situation for which it is inappropriate, then you'll get the same results with a portable SMTP server that you would sending through a properly configured static server. So, no, use DKIM does not address the delivery difficulties inherent to using a portable SMTP server. My how the goalposts are moving. DKIM solves the problem of producing a stable identifier for a mail stream which is what your originally positioned goalposts was asking for. It also makes reverse dns lookups even more useless than they already are. Mike
Re: The End-To-End Internet (was Re: Blocking MX query)
On 09/05/2012 03:01 PM, Michael Thomas wrote: On 09/05/2012 12:50 PM, Daniel Taylor wrote: On 09/05/2012 10:19 AM, Michael Thomas wrote: On 09/05/2012 05:56 AM, Daniel Taylor wrote: On 09/04/2012 03:52 PM, Michael Thomas wrote: On 09/04/2012 09:34 AM, Daniel Taylor wrote: If you are sending direct SMTP on behalf of your domain from essentially random locations, how are we supposed to pick you out from spammers that do the same? Use DKIM. You say that like it's a lower bar than setting up a fixed SMTP server and using that. I say it like it addresses your concern. Well, if you've got proper forward and reverse DNS, and your portable SMTP server identifies itself properly, and you are using networks that don't filter outbound port 25, AND you have DKIM configured correctly and aren't using it for a situation for which it is inappropriate, then you'll get the same results with a portable SMTP server that you would sending through a properly configured static server. So, no, use DKIM does not address the delivery difficulties inherent to using a portable SMTP server. My how the goalposts are moving. DKIM solves the problem of producing a stable identifier for a mail stream which is what your originally positioned goalposts was asking for. It also makes reverse dns lookups even more useless than they already are. Use your MX or SPF senders as your outbound mail agent, especially if they are properly configured with full DNS records so we can tell they are the correct machines to be sending on your behalf, or expect that you will get more mail bounced and lost than the average user because you are being unpredictable and unverifiable. That you so conveniently trimmed from the post that you replied to. Just putting the goalposts back where I left them. Proper DNS configuration is essential to reliable SMTP delivery. SPF and DKIM can help ensure you don't get mistakenly tagged as a spammer, but they are no substitute for proper technical configuration of your mail server, and you don't get proper configuration if you are using other people's networks. -- Daniel Taylor VP Operations Vocal Laboratories, Inc dtay...@vocalabs.com 952-941-6580x203
Re: The End-To-End Internet (was Re: Blocking MX query)
On Wed, Sep 05, 2012 at 11:46:34AM -0400, Greg Ihnen wrote: On Wed, Sep 5, 2012 at 11:11 AM, Izaac iz...@setec.org wrote: On Wed, Sep 05, 2012 at 07:50:12AM -0700, Henry Stryker wrote: signature. They are adaptive, like cockroaches. This is why tcp port 25 filtering is totally effective and will remain so forever. Definitely worth breaking basic function principles of a global communications network over which trillions of dollars of commerce occur. But as someone pointed out further back on this thread people who want to have their mail servers available to people who are on the other side of port 25 filtering just use the alternate ports. So then what does filtering port 25 accomplish? I suspect your ISP is also stripping sarcasm tags. Let's try it out again: You can tell that tcp port 25 filtering is a highly effective spam mitigation technique because spam levels have declined in direct proportion to their level of deployment. Today, we barely see any spam on the internet due to amazing ability of these filters to prevent bad people from sending bulk email. Was that properly marked? Or this one? Since tcp25 filtering has been so successful, we should deploy filters for everything except tcp80 and tcp443 and maaaybe tcp21 -- but NAT already does so much to enhance the user experience there already. And what with ISP customers using their provided DNS and mail service exclusively, there's no reason to permit udp53, tcp110, tcp143, tcp993, tcp995 either. Really, only evil people use anything but the web. Any other traffic undoubtedly a bot from which they ought to be protected. -- . ___ ___ . . ___ . \/ |\ |\ \ . _\_ /__ |-\ |-\ \__
Re: The End-To-End Internet (was Re: Blocking MX query)
Izaac iz...@setec.org commented: #I suspect your ISP is also stripping sarcasm tags. Let's try it out #again: # # You can tell that tcp port 25 filtering is a highly effective spam # mitigation technique because spam levels have declined in direct # proportion to their level of deployment. Today, we barely see any # spam on the internet due to amazing ability of these filters to # prevent bad people from sending bulk email. # #Was that properly marked? Actually, not sure sarcasm tags are appropriate. 1) Port 25 blocks target direct-to-MX spam delivered by bots. 2) The Spamhaus CBL tracks the level of bot spam currently seen, including breaking out statistics by a number of factors. 3) Currently, the US, where port 25 filtering is routinely deployed by most large ISPs, is ranked 158th among countries when you consider botted users on a per capita basis: http://cbl.abuseat.org/countrypercapita.html 4) While that's not perfect (after all, there are still at least 133,811 listings for the US), on a PER-CAPITA basis, it's not bad -- that's just ~0.055% of US Internet users that are infected, relative to some countries where the rate of detected infection (based on spam emission) may be 4 to 5% or more. So yes, actually, port 25 blocks *DO* tend to be effective in reducing bot-delivered email spam. Does this mean that port 25 blocks are the ONLY measure that is required to control spam? No, absolutely not. But it does clearly help. Regards, Joe
Re: The End-To-End Internet (was Re: Blocking MX query)
On Tue, Sep 04, 2012 at 03:45:32PM -0400, William Herrin wrote: That's what firewalls *are for* Jay. They intentionally break end-to-end for communications classified by the network owner as undesirable. Whether a particular firewall employs NAT or not is largely beside the point here. Either way, the firewall is *supposed* to break some of the end to end communication paths. Which has had two basic results: First, we've raised at least two generations of programmers who cannot write a network-facing service able to stand up in so much as a stiff breeze. Well it's behind the firewall, so no one will be able to see it. Second, we've killed -- utterly and completely -- countless promising technologies and forced the rest to somehow figure out either how to pretend to be HTTP or tunnel themselves. That's just sad. But even then, we're not talking about an end user choosing not to permit certain kinds of inbound connectivity. We're talking about carriers inspecting and selectively interfering with (and in some cases outright manipulating) communication in transit. That's just plain wrong. -- . ___ ___ . . ___ . \/ |\ |\ \ . _\_ /__ |-\ |-\ \__
Re: The End-To-End Internet (was Re: Blocking MX query)
On Sep 5, 2012, at 5:12 PM, Izaac iz...@setec.org wrote: Since tcp25 filtering has been so successful, we should deploy filters for everything except tcp80 and tcp443 and maaaybe tcp21 -- but NAT already does so much to enhance the user experience there already. And what with ISP customers using their provided DNS and mail service exclusively, there's no reason to permit udp53, tcp110, tcp143, tcp993, tcp995 either. Really, only evil people use anything but the web. Any other traffic undoubtedly a bot from which they ought to be protected. Izaac, You do realize that that the NANOG mailing is archived and some helpful person will quote you to their favorite legislator? James R. Cutler james.cut...@consultant.com
Re: The End-To-End Internet (was Re: Blocking MX query)
On Wed, Sep 5, 2012 at 5:12 PM, Izaac iz...@setec.org wrote: I suspect your ISP is also stripping sarcasm tags. Let's try it out again: You can tell that tcp port 25 filtering is a highly effective spam mitigation technique because spam levels have declined in direct proportion to their level of deployment. Today, we barely see any spam on the internet due to amazing ability of these filters to prevent bad people from sending bulk email. Thing is, spam levels *are* down a good 20% in the last couple years, that being about the time ISPs began doing this. More, 20% *is* in rough proportion the impacted customer counts on the handful of cable and DSL providers that implemented it. And if you remind me that correlation is not causation I'll have to point out the same flaw in your more sarcastic version. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: The End-To-End Internet (was Re: Blocking MX query)
In article 5047a2ea.8010...@hup.org you write: On 09/05/12 09:13 , Michael Thomas wrote: The I part of DKIM is Identified. That's all it promises. It's a feature, not a bug, that spammers use it. Which is why DKIM does not really address any concerns. The spammers have reduced its value. Nothing personal, but nobody who had the most rudimentary understanding of what DKIM does and how it's intended to be used would make such a statement. See the archives of the IETF DKIM list for much, much, much more detail. R's, John
Re: The End-To-End Internet (was Re: Blocking MX query)
Well, if you've got proper forward and reverse DNS, and your portable SMTP server identifies itself properly, and you are using networks that don't filter outbound port 25, AND you have DKIM configured correctly and aren't using it for a situation for which it is inappropriate, then you'll get the same results with a portable SMTP server that you would sending through a properly configured static server. Not really. Large mail system like Gmail and Yahoo have a pretty good map of the IPv4 address space. If you're sending from a residential DSL or cable modem range, they'll likely reject any mail you send directly no matter what you do. R's, John
Re: The End-To-End Internet (was Re: Blocking MX query)
On 05 Sep 2012 23:07:07 -, John Levine said: Not really. Large mail system like Gmail and Yahoo have a pretty good map of the IPv4 address space. If you're sending from a residential DSL or cable modem range, they'll likely reject any mail you send directly no matter what you do. Which is why I finally gave up and speak to an 800 pound gorilla on port 587, because nobody dares to mess with that gorilla's port 587 so my laptop can always get mail sent. :) pgpurhUgUjkBA.pgp Description: PGP signature
Re: The End-To-End Internet (was Re: Blocking MX query)
On 9/4/12, Jay Ashworth j...@baylink.com wrote: It is regularly alleged, on this mailing list, that NAT is bad *because it violates the end-to-end principle of the Internet*, where each host is a full-fledged host, able to connect to any other host to perform transactions. Both true. and NAT inherently breaks the end-to-end principal for all the applications. Blocking port 25 traffic, also breaks the possibility of end-to-end communications on that one port. But not for the SMTP protocol. SMTP End-to-End is preserved, as long as the SMTP relay provided does not introduce further restrictions. We see it now alleged that the opposite is true: that a laptop, say, like mine, which runs Linux and postfix, and does not require a smarthost to deliver mail to a remote server *is a bad actor* *precisely because it does that* (in attempting to send mail directly to a domain's MX server) *from behind a NAT router*, and possibly different ones at different times. Ding ding ding... behind a NAT router. The End-to-End principal is already broken. The 1:many NAT router prevents your host from being specifically identified, in order to efficiently and adequately identify, report, and curtail abuse; You can't break the end-to-end principal in cases where it has already been broken. And selectively breaking end-to-end in limited circumstances is OK. You choose to break it when the damage can be mitigated and the concerns that demand breaking it are strong enough. The end-to-end principal as you suggest primarily pertains to the Internet protocol; IP and TCP. I believe you are trying to apply the principal in an inappropriate way for the layer you are applying it to. At the SMTP application layer end-to-end internet connectivity means you can send e-mail to any e-mail address and receive e-mail from any e-mail address. For HTTP; that would mean you can retrieve a page from any host, and any remote HTTP client, can retrieve an page from your hosts; that doesn't necessarily imply that the transaction will be allowed, but if it is refused -- it is for an administrative reason, not due to a design flaw. NAT would fall under design flaw, because it breaks end-to-end connectivity, such that there is no longer an administrative choice that can be made to restore it (other than redesign with NAT removed). At the transport layer, end-to-end means you can establish connections on various ports to any peer on the internet, and any peer can connect to all ports on which you allow. It doesn't necessarily mean that all ports are allowed; a remote host, or a firewall under their control, deciding to block your connection is not a violation of end-to-end. At the internet layer, end-to-end means you can send any datagram to any host on the internet it will be delivered to that host; and any host can send a datagram to you.It doesn't mean that none of your packets will be discarded on the way, because some specific application or port has been banned. At the link layer, there is no end-to-end connectivity; it is at IP that the notion first arises. I find these conflicting reports very conflicting. Either the end-to-end principle *is* the Prime Directive... or it is *not*. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 -- -JH
Re: The End-To-End Internet (was Re: Blocking MX query)
On Sep 5, 2012, at 19:07, John Levine wrote: Not really. Large mail system like Gmail and Yahoo have a pretty good map of the IPv4 address space. If you're sending from a residential DSL or cable modem range, they'll likely reject any mail you send directly no matter what you do. While I've clearly been on the side of don't expect this to work, why do you have your laptop set up like that?, and defending the default-blocking behavior on outbound, this is not true at least for Gmail. I have a test Asterisk box which I've been really lazy about setting up properly that successfully sends status messages from my home cable modem to my Gmail-hosted personal domain every day, even getting through with a completely bogus source address. It's never even been flagged as possible spam. Maybe Gmail does more detailed analysis of some kind and sees that I'm also checking my email from the same IP that's sending these messages, I don't know, but they are not just blocking anything coming in from a random cable IP. I'll bet it raises the spam likelihood or whatever as it probably should, but it's not a total block. --- Sean Harlow s...@seanharlow.info
Re: The End-To-End Internet (was Re: Blocking MX query)
On 9/5/12, Sean Harlow s...@seanharlow.info wrote: While I've clearly been on the side of don't expect this to work, why do you have your laptop set up like that?, and defending the default-blocking behavior on outbound, this is not true at least for Gmail. I have a test Asterisk box which I've been really lazy about setting up properly that I would still file it under... yes, there will probably be many mail hosts you can contact that way. It will be understandable if many block it, but they don't have to. If they give you a smart host, then you should use that. End-to-End doesn't imply control of the routing in-between smtp origin and destination. It will also be understandable if the ISP blocks outbound port 25, but they don't have to. Personally I would rather they not -- blocking port 25 doesn't make the underlying problem go away; it's just a way of hiding the problem, so the ISP isn't pestered about it. By blocking port 25; the ISP doesn't receive a spam complaint for blocked non-legit activity, so they have fewer network abuse reports to deal with. Fewer users to turn off = fewer angered users switching to other providers (Even if turning off the user in response to spam will help the user, by alerting them to their compromised computer). End user Having to use a smart relay host increases latency and introduces a point of failure (ISP mail relay can fail or perform unacceptably even when the network has no issues). If you have the intelligence on your laptop to properly contact MX hosts; the restriction can be a hinderance, and it is difficult to justify. The ISP could block port 25 on report of abuse; but I suppose... incident handlers' time reading abuse reports = $$$ Once the large ISPs do the math, it is understandable if their ISP organizations' management eventually opts to block port 25. For the ones who didn't choose to do that; presumably sufficient users complained or they feared the competition would be strengthened or charged with their unpopular choice. My idealistic preference would be the ISP allows outbound port 25, but are highly responsive to abuse complaints; that way, the problem will be corrected, instead of festering, until some day the laptop gets plugged into some network that happens to allow the port. Or spreads the infection, because of the port 25 block, the problem goes undetected and contributes to making the overall worse. Just because a compromised host can't connect on port 25; doesn't mean it is not a significant contribution to the problem. Spreading infection via other vectors; spamming via other vectors such as IM, Forum posts, HTTP contact/feedback forms... There are plenty of abusive non port-25 activities that ultimately facilitate spamming. -- -JH
Re: The End-To-End Internet (was Re: Blocking MX query)
Jimmy Hess wrote: NAT would fall under design flaw, because it breaks end-to-end connectivity, such that there is no longer an administrative choice that can be made to restore it (other than redesign with NAT removed). The end to end transparency can be restored easily, if an administrator wishes so, with UPnP capable NAT and modified host transport layer. That is, the administrator assigns a set of port numbers to a host behind NAT and sets up port mapping. (global IP, global port) - (local IP, global port) then, if transport layer of the host is modified to perform reverse translation (information for the translation can be obtained through UPnP): (local IP, global port) - (global IP, global port) Now, NAT is transparent to application layer. The remaining restrictions are that only TCP and UDP are supported by UPnP (see draft-ohta-e2e-nat-00.txt for a specialized NAT box to allow more general transport layers) and that a set of port numbers available to the application layer is limited (you may not be able to run a SMTP server at port 25). The point of the end to end transparency is: The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system. quoted from End-To-End Arguments in System Design, the original paper on the end to end argument written by Saltzer et. al. Thus, The NAT function can completely and correctly be implemented with the knowledge and help of the host protocol stack. Masataka Ohta
Re: The End-To-End Internet (was Re: Blocking MX query)
On Thu, 06 Sep 2012 13:08:29 +0900, Masataka Ohta said: The end to end transparency can be restored easily, if an administrator wishes so, with UPnP capable NAT and modified host transport layer. How does the *second* host behind the NAT that wants to use global port 7719 do it? pgpgNE8JDz2TX.pgp Description: PGP signature
Re: The End-To-End Internet (was Re: Blocking MX query)
(2012/09/06 13:15), valdis.kletni...@vt.edu wrote: On Thu, 06 Sep 2012 13:08:29 +0900, Masataka Ohta said: The end to end transparency can be restored easily, if an administrator wishes so, with UPnP capable NAT and modified host transport layer. How does the *second* host behind the NAT that wants to use global port 7719 do it? In the previous mails, I wrote: The remaining restrictions are that ... and that a set of port numbers available to the application layer is limited (you may not be able to run a SMTP server at port 25). and Jimmy wrote: At the transport layer, end-to-end means you can establish connections on various ports to any peer on the internet, and any peer can connect to all ports on which you allow. It doesn't necessarily mean that all ports are allowed; a remote host, or a firewall under their control, deciding to block your connection is not a violation of end-to-end. Masataka Ohta
Re: The End-To-End Internet (was Re: Blocking MX query)
On Sep 5, 2012, at 21:08 , Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: Jimmy Hess wrote: NAT would fall under design flaw, because it breaks end-to-end connectivity, such that there is no longer an administrative choice that can be made to restore it (other than redesign with NAT removed). The end to end transparency can be restored easily, if an administrator wishes so, with UPnP capable NAT and modified host transport layer. This is every bit as much BS as it was the first 6 times you pushed it. That is, the administrator assigns a set of port numbers to a host behind NAT and sets up port mapping. (global IP, global port) - (local IP, global port) then, if transport layer of the host is modified to perform reverse translation (information for the translation can be obtained through UPnP): (local IP, global port) - (global IP, global port) Now, NAT is transparent to application layer. Never mind the fact that all the hosts trying to reach you have no way to know what port to use. http://www.foo.com fed into a browser has no way for the browser to determine that it needs to contact 192.0.200.50 on port 8099 instead of port 80. The remaining restrictions are that only TCP and UDP are supported by UPnP (see draft-ohta-e2e-nat-00.txt for a specialized NAT box to allow more general transport layers) and that a set of port numbers available to the application layer is limited (you may not be able to run a SMTP server at port 25). You're demanding an awful lot of changes to the entire internet to partially restore IPv4 transparency when the better solution is to deploy IPv6 and have real full transparency. The point of the end to end transparency is: The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system. That is one purpose. A more accurate definition of the greater purpose of end-to-end transparency would be: An application can expect the datagram to arrive at the remote destination without any modifications not specified in the basic protocol requirements (e.g. TTL decrements, mac layer header rewrites, reformatting for different lower-layer media, etc.) An application should be able to expect the layer 3 and above addressing elements to be unaltered and to be able to provide contact me on style messages in the payload based on its own local knowledge of its addressing. quoted from End-To-End Arguments in System Design, the original paper on the end to end argument written by Saltzer et. al. Thus, The NAT function can completely and correctly be implemented with the knowledge and help of the host protocol stack. Masataka Ohta It could be argued, if one considers contact me on style messages to be valid, that the function cannot be completely and correctly implemented in the presence of NAT. Moreover, since NAT provides no benefit other than address compression and the kind of additional effort on NAT of which you speak would be a larger development effort than IPv6 at this point, why bother? Owen
Re: The End-To-End Internet (was Re: Blocking MX query)
On Wed, Sep 5, 2012 at 9:39 PM, Owen DeLong o...@delong.com wrote: On Sep 5, 2012, at 21:08 , Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: Jimmy Hess wrote: NAT would fall under design flaw, because it breaks end-to-end connectivity, such that there is no longer an administrative choice that can be made to restore it (other than redesign with NAT removed). The end to end transparency can be restored easily, if an administrator wishes so, with UPnP capable NAT and modified host transport layer. This is every bit as much BS as it was the first 6 times you pushed it. Yep.
Re: The End-To-End Internet (was Re: Blocking MX query)
Owen DeLong wrote: then, if transport layer of the host is modified to perform reverse translation (information for the translation can be obtained through UPnP): (local IP, global port) - (global IP, global port) Now, NAT is transparent to application layer. Never mind the fact that all the hosts trying to reach you have no way to know what port to use. Quote from draft-ohta-e2e-nat-00.txt A server port number different from well known ones may be specified through mechanisms to specify an address of the server, which is the case of URLs. http://www.foo.com fed into a browser has no way for the browser to determine that it needs to contact 192.0.200.50 on port 8099 instead of port 80. See RFC6281 and draft-ohta-urlsrv-00.txt. But, http://www.foo.com:8099 works just fine. The remaining restrictions are that only TCP and UDP are supported by UPnP (see draft-ohta-e2e-nat-00.txt for a specialized NAT box to allow more general transport layers) and that a set of port numbers available to the application layer is limited (you may not be able to run a SMTP server at port 25). You're demanding an awful lot of changes to the entire internet to All that necessary is local changes on end systems of those who want the end to end transparency. There is no changes on the Internet. This is every bit as much BS as it was the first 6 times you pushed it. As you love BS so much, you should better read your own mails. Masataka Ohta
Re: The End-To-End Internet (was Re: Blocking MX query)
On 9/4/12 9:05 AM, Jay Ashworth wrote: - Original Message - From: John Peach john-na...@johnpeach.com On Tue, 4 Sep 2012 11:57:38 -0400 (EDT) Jay Ashworth j...@baylink.com wrote: SMTP Auth to *arbitrary remote domains' MX servers*? Am I missing something, or are you? I run an MTA on my server and auth to that from laptops and other clients. Relaying allowed for authorised users. So, in other words, it's ok to rant and stomp our feet about the end-to-end architecture and how critical it is to support in order to diss NAT, but we're required to ignore it when discussing SMTP? I'm not sure I'm following, there. Feelings on spam = this is why we can't have nice things ~Seth
Re: The End-To-End Internet (was Re: Blocking MX query)
- Original Message - From: Owen DeLong o...@delong.com I am confused... I don't understand your comment. It is regularly alleged, on this mailing list, that NAT is bad *because it violates the end-to-end principle of the Internet*, where each host is a full-fledged host, able to connect to any other host to perform transactions. We see it now alleged that the opposite is true: that a laptop, say, like mine, which runs Linux and postfix, and does not require a smarthost to deliver mail to a remote server *is a bad actor* *precisely because it does that* (in attempting to send mail directly to a domain's MX server) *from behind a NAT router*, and possibly different ones at different times. I find these conflicting reports very conflicting. Either the end-to-end principle *is* the Prime Directive... or it is *not*. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: The End-To-End Internet (was Re: Blocking MX query)
On Sep 4, 2012, at 14:22, Jay Ashworth wrote: I find these conflicting reports very conflicting. Either the end-to-end principle *is* the Prime Directive... or it is *not*. Just because something is of extremely high importance does not mean it still can't be overridden when there's good enough reason. In this case, in the majority of random computer on the internet IP blocks the ratio of spambots to legitimate mail senders is so far off balance that a whitelisting approach to allowing outbound port 25 traffic is not unreasonable. Unlike the bad kinds of NAT, this doesn't also indiscriminately block thousands of other uses, it exclusively affects email traffic in a way which is trivial for the legitimate user to work around while stopping the random infected hosts in their tracks. Many providers also block traffic on ports like 137 (NetBIOS) on consumer space for similar reasons, the malicious or unwanted uses vastly outweigh the legitimate ones. The reason bad NATs get dumped on is because there are better solutions both known and available on the market. If you have an idea for a way to allow your laptop to send messages directly while still stopping or minimizing the ability of the thousands of zombies sharing an ISP with you from doing the same the world would love to hear it. --- Sean Harlow s...@seanharlow.info
Re: The End-To-End Internet (was Re: Blocking MX query)
On Tue, Sep 4, 2012 at 2:22 PM, Jay Ashworth j...@baylink.com wrote: It is regularly alleged, on this mailing list, that NAT is bad *because it violates the end-to-end principle of the Internet*, where each host is a full-fledged host, able to connect to any other host to perform transactions. That's what firewalls *are for* Jay. They intentionally break end-to-end for communications classified by the network owner as undesirable. Whether a particular firewall employs NAT or not is largely beside the point here. Either way, the firewall is *supposed* to break some of the end to end communication paths. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: The End-To-End Internet (was Re: Blocking MX query)
On 9/4/2012 2:22 PM, Jay Ashworth wrote: - Original Message - From: Owen DeLong o...@delong.com I am confused... I don't understand your comment. It is regularly alleged, on this mailing list, that NAT is bad *because it violates the end-to-end principle of the Internet*, where each host is a full-fledged host, able to connect to any other host to perform transactions. We see it now alleged that the opposite is true: that a laptop, say, like mine, which runs Linux and postfix, and does not require a smarthost to deliver mail to a remote server *is a bad actor* *precisely because it does that* (in attempting to send mail directly to a domain's MX server) *from behind a NAT router*, and possibly different ones at different times. I find these conflicting reports very conflicting. Either the end-to-end principle *is* the Prime Directive... or it is *not*. The end-to-end design principle pushes application functions to endpoints instead of placing these functions in the network itself. This principle requires that endpoints be *capable* of creating connections to each other. Network system design must support these connections being initiated by either side - which is where NAT implementations usually fail. There is no requirement that all endpoints be *permitted* to connect to and use any service of any other endpoint. The end-to-end design principle does not require a complete lack of authentication or authorization. I can refuse connections to port 25 on my endpoint (mail server) from hosts that do not conform to my requirements (e.g. those that do not have forward-confirmed reverse DNS) without violating the end-to-end design principle in any way. Thus it is a false chain of conclusions to say that: - end-to-end is violated by restricting connections to/from certain hosts [therefore] - the end-to-end design principle is not important [therefore] - NAT is good ...which I believe is the argument that was being made? ... Ref - http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf Cheers, -- jra
Re: The End-To-End Internet (was Re: Blocking MX query)
- Original Message - From: William Herrin b...@herrin.us That's what firewalls *are for* Jay. They intentionally break end-to-end for communications classified by the network owner as undesirable. Whether a particular firewall employs NAT or not is largely beside the point here. Either way, the firewall is *supposed* to break some of the end to end communication paths. Correct, Bill. Hopefully, everyone else here who thinks DNAT is the anti-Christ heard the largely beside the point part of your assertion, with which I agree. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: The End-To-End Internet (was Re: Blocking MX query)
On 09/04/2012 01:07 PM, David Miller wrote: There is no requirement that all endpoints be *permitted* to connect to and use any service of any other endpoint. The end-to-end design principle does not require a complete lack of authentication or authorization. I can refuse connections to port 25 on my endpoint (mail server) from hosts that do not conform to my requirements (e.g. those that do not have forward-confirmed reverse DNS) without violating the end-to-end design principle in any way. The thing that has never set well with me with ISP blanket port 25 blocking is that the fate sharing is not correct. If I have a mail server and I refuse to take incoming connects from dynamic home IP blocks, the fate sharing is correct: I'm only hurting myself if there's collateral damage. When ISP's have blanket port 25, the two parties of the intended conversation never get a say: things just break mysteriously as far as both parties are concerned, but the ISP isn't hurt at all. So they have no incentive to drop their false positive rate. That's not good. Mike
Re: The End-To-End Internet (was Re: Blocking MX query)
If you are sending direct SMTP on behalf of your domain from essentially random locations, how are we supposed to pick you out from spammers that do the same? Use your MX or SPF senders as your outbound mail agent, especially if they are properly configured with full DNS records so we can tell they are the correct machines to be sending on your behalf, or expect that you will get more mail bounced and lost than the average user because you are being unpredictable and unverifiable. On 09/04/2012 11:05 AM, Jay Ashworth wrote: - Original Message - From: John Peach john-na...@johnpeach.com On Tue, 4 Sep 2012 11:57:38 -0400 (EDT) Jay Ashworth j...@baylink.com wrote: SMTP Auth to *arbitrary remote domains' MX servers*? Am I missing something, or are you? I run an MTA on my server and auth to that from laptops and other clients. Relaying allowed for authorised users. So, in other words, it's ok to rant and stomp our feet about the end-to-end architecture and how critical it is to support in order to diss NAT, but we're required to ignore it when discussing SMTP? I'm not sure I'm following, there. Cheers, -- jra -- Daniel Taylor VP Operations Vocal Laboratories, Inc dtay...@vocalabs.com 952-941-6580x203
Re: The End-To-End Internet (was Re: Blocking MX query)
On 09/04/2012 09:34 AM, Daniel Taylor wrote: If you are sending direct SMTP on behalf of your domain from essentially random locations, how are we supposed to pick you out from spammers that do the same? Use DKIM. Mike
