On 9/11/12, Masataka Ohta 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
>
(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
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 followin
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 pa
>
> 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
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 wor
On 9/6/12, Masataka Ohta 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
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
On Sun, Sep 9, 2012 at 6:24 PM, Masataka Ohta
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
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
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
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 al
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 158t
On Tue, Sep 4, 2012 at 3:45 PM, William Herrin wrote:
> On Tue, Sep 4, 2012 at 2:22 PM, Jay Ashworth 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
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 transparenc
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 c
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 pr
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 th
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
On Sep 6, 2012, at 23:30 , Masataka Ohta
wrote:
> 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
On Sep 6, 2012, at 22:31 , Sean Harlow 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
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 i
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 r
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.klet
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 po
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 suppo
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 cla
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 g
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 argum
On Sep 6, 2012, at 08:14 , Andrew Sullivan 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
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
On Thu, Sep 6, 2012 at 11:14 AM, Andrew Sullivan 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 mech
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
expe
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. Globa
>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, a
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% *
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 m
On Wed, Sep 5, 2012 at 9:39 PM, Owen DeLong wrote:
>
> On Sep 5, 2012, at 21:08 , Masataka Ohta
> 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 re
On Sep 5, 2012, at 21:08 , Masataka Ohta
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
(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
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?
pgpgNE8JD
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
administra
On 9/5/12, Sean Harlow 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 real
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
On 9/4/12, Jay Ashworth 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 br
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.
W
>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
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
On Wed, Sep 5, 2012 at 5:12 PM, Izaac wrote:
> I suspect your ISP is also stripping 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 de
On Sep 5, 2012, at 5:12 PM, Izaac 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 us
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. Eith
Izaac commented:
#I suspect your ISP is also stripping 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
On Wed, Sep 05, 2012 at 11:46:34AM -0400, Greg Ihnen wrote:
> On Wed, Sep 5, 2012 at 11:11 AM, Izaac 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 w
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 sendin
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 ess
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
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 serve
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
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
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?
Th
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. Rest
On Wed, Sep 5, 2012 at 11:11 AM, Izaac 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 effectiv
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
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
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, li
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
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
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
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
- Original Message -
> From: "William Herrin"
> 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,
On 9/4/2012 2:22 PM, Jay Ashworth wrote:
> - Original Message -
>> From: "Owen DeLong"
>
>> 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
On Tue, Sep 4, 2012 at 2:22 PM, Jay Ashworth 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 f
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 en
- Original Message -
> From: "Owen DeLong"
> 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 ot
On 9/4/12 9:05 AM, Jay Ashworth wrote:
> - Original Message -
>> From: "John Peach"
>
>> On Tue, 4 Sep 2012 11:57:38 -0400 (EDT)
>> Jay Ashworth wrote:
>>> SMTP Auth to *arbitrary remote domains' MX servers*? Am I missing
>>> something,
>>> or are you?
>>
>> I run an MTA on my server and
- Original Message -
> From: "John Peach"
> On Tue, 4 Sep 2012 11:57:38 -0400 (EDT)
> Jay Ashworth 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.
76 matches
Mail list logo
