Yes. Till that hotspots IP space gets blackholed by a major freemail because of all the nigerians and hijacked devices emitting bot traffic through stolen auth credentials. There's other ways to stop this but they take actual hard work and rather more gear than a rusted up old asa you pull out of your closet as like as not. On Nov 28, 2014 2:10 AM, "Mark Andrews" <marka@isc.org> wrote:

Which is why your MTA should always be setup to require the use of STARTTLS. Additionally the CERT presented should also match the name of the server.

There is absolutely no reason for a ISP / hotspot to inspect submission traffic. The "stopping spam" argument doesn't wash with submission.

Mark

In message <54778167.7080808@bogus.com>, joel jaeggli writes:

...

I don't see this in my home market, but I do see it in someone else's... I kind of expect this for port 25 but...

J@mb-aye:~$telnet 147.28.0.81 587 Trying 147.28.0.81... Connected to nagasaki.bogus.com. Escape character is '^]'. 220 nagasaki.bogus.com ESMTP Sendmail 8.14.9/8.14.9; Thu, 27 Nov 2014 19:17:44 GMT ehlo bogus.com 250-nagasaki.bogus.com Hello XXXXXXXXXXXXXXX.wa.comcast.net [XXX.XXX.XXX.XXX], pleased to meet you 250 ENHANCEDSTATUSCODES

J@mb-aye:~$telnet 2001:418:1::81 587 Trying 2001:418:1::81... Connected to nagasaki.bogus.com. Escape character is '^]'. 220 nagasaki.bogus.com ESMTP Sendmail 8.14.9/8.14.9; Thu, 27 Nov 2014 19:18:33 GMT ehlo bogus.com 250-nagasaki.bogus.com Hello [IPv6:2601:7:2380:XXXX:XXXX:XXXX:c1ae:7d73], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-8BITMIME 250-SIZE 250-DSN 250-AUTH DIGEST-MD5 CRAM-MD5 LOGIN 250-STARTTLS 250-DELIVERBY 250 HELP

that's essentially a downgrade attack on my ability to use encryption which seems to be in pretty poor taste frankly.

-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

Oh it depends on the numbers. Just how many legitimate smtp submission attempts do you get from say an access point at Joes diner in nowhere, OH? Versus just how many password cracking and malware relay attempts across how many of your users, from an unpatched xp box the guy is using for a billing app? At the scale of the problem a provider with any kind of userbase faces, you need a chainsaw, not a scalpel, given that you're out to cut a tree rather than perform plastic surgery. On Nov 28, 2014 6:08 AM, "Mark Andrews" <marka@isc.org> wrote:

In message <CAArzuouvhnHo7BbAWUwiR3=m0x2O6Qe= 2qLcvb29i07OaX-yqg@mail.gmail.com> , Suresh Ramasubramanian writes:

...

Yes. Till that hotspots IP space gets blackholed by a major freemail because of all the nigerians and hijacked devices emitting bot traffic through stolen auth credentials.

Why would it black hole the address rather than the block the compromised credentials? The whole point of submission is to authenticate the submitter and to be able to trace spam back to the submitter and deal with the issue at that level of granuality.

Blocking at that level also stop the credentials being used from anywhere.

scalpel vs chainsaw.

Just because you provide free email doesn't give you the right to not do the service properly. You encouraged people to use your service. You should resource it to deal with the resulting load and that includes dealing with spam and scans being sent with stolen credentials. As a free email provider you have the plain text.

Mark

...

There's other ways to stop this but they take actual hard work and rather more gear than a rusted up old asa you pull out of your closet as like as not. On Nov 28, 2014 2:10 AM, "Mark Andrews" <marka@isc.org> wrote:

...

Which is why your MTA should always be setup to require the use of STARTTLS. Additionally the CERT presented should also match the name of the server.

There is absolutely no reason for a ISP / hotspot to inspect submission traffic. The "stopping spam" argument doesn't wash with submission.

Mark

In message <54778167.7080808@bogus.com>, joel jaeggli writes:

...

I don't see this in my home market, but I do see it in someone

else's...

...

...

I kind of expect this for port 25 but...

J@mb-aye:~$telnet 147.28.0.81 587 Trying 147.28.0.81... Connected to nagasaki.bogus.com. Escape character is '^]'. 220 nagasaki.bogus.com ESMTP Sendmail 8.14.9/8.14.9; Thu, 27 Nov 2014 19:17:44 GMT ehlo bogus.com 250-nagasaki.bogus.com Hello XXXXXXXXXXXXXXX.wa.comcast.net [XXX.XXX.XXX.XXX], pleased to meet you 250 ENHANCEDSTATUSCODES

J@mb-aye:~$telnet 2001:418:1::81 587 Trying 2001:418:1::81... Connected to nagasaki.bogus.com. Escape character is '^]'. 220 nagasaki.bogus.com ESMTP Sendmail 8.14.9/8.14.9; Thu, 27 Nov 2014 19:18:33 GMT ehlo bogus.com 250-nagasaki.bogus.com Hello [IPv6:2601:7:2380:XXXX:XXXX:XXXX:c1ae:7d73], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-8BITMIME 250-SIZE 250-DSN 250-AUTH DIGEST-MD5 CRAM-MD5 LOGIN 250-STARTTLS 250-DELIVERBY 250 HELP

that's essentially a downgrade attack on my ability to use encryption which seems to be in pretty poor taste frankly. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

--bcaec517c6c01f783d0508e015a5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">Yes. Till that hotspots IP space gets blackholed by a major = freemail because of all the nigerians and hijacked devices emitting bot tra= ffic through stolen auth credentials. </p> <p dir=3D"ltr">There's other ways to stop this but they take actual har= d work and rather more gear than a rusted up old asa you pull out of your c= loset as like as not. <br> </p> <div class=3D"gmail_quote">On Nov 28, 2014 2:10 AM, "Mark Andrews"= ; <<a href=3D"mailto:marka@isc.org">marka@isc.org</a>> wrote:<br type= =3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8= ex;border-left:1px #ccc solid;padding-left:1ex"><br> Which is why your MTA should always be setup to require the use of<br> STARTTLS.=C2=A0 Additionally the CERT presented should also match the<br> name of the server.<br> <br> There is absolutely no reason for a ISP / hotspot to inspect<br> submission traffic.=C2=A0 The "stopping spam" argument doesn'= t wash with<br> submission.<br> <br> Mark<br> <br> In message <<a href=3D"mailto:54778167.7080808@bogus.com ">54778167.70808= 08@bogus.com</a>>, joel jaeggli writes:<br> ><br> > I don't see this in my home market, but I do see it in someone els= e's...<br> > I kind of expect this for port 25 but...<br> ><br> > J@mb-aye:~$telnet 147.28.0.81 587<br> > Trying 147.28.0.81...<br> > Connected to <a href=3D"http://nagasaki.bogus.com" target=3D"_blank">n= agasaki.bogus.com</a>.<br> > Escape character is '^]'.<br> > 220 <a href=3D"http://nagasaki.bogus.com" target=3D"_blank">nagasaki.b= ogus.com</a> ESMTP Sendmail 8.14.9/8.14.9; Thu, 27 Nov 2014<br> > 19:17:44 GMT<br> > ehlo <a href=3D"http://bogus.com" target=3D"_blank">bogus.com </a><br> > <a href=3D"http://250-nagasaki.bogus.com" target=3D"_blank">250-nagasa= ki.bogus.com</a> Hello <a href=3D"http://XXXXXXXXXXXXXXX.wa.comcast.net" ta= rget=3D"_blank">XXXXXXXXXXXXXXX.wa.comcast.net</a><br> > [XXX.XXX.XXX.XXX], pleased to meet you<br> > 250 ENHANCEDSTATUSCODES<br> ><br> > J@mb-aye:~$telnet 2001:418:1::81 587<br> > Trying 2001:418:1::81...<br> > Connected to <a href=3D"http://nagasaki.bogus.com" target=3D"_blank">n= agasaki.bogus.com</a>.<br> > Escape character is '^]'.<br> > 220 <a href=3D"http://nagasaki.bogus.com" target=3D"_blank">nagasaki.b= ogus.com</a> ESMTP Sendmail 8.14.9/8.14.9; Thu, 27 Nov 2014<br> > 19:18:33 GMT<br> > ehlo <a href=3D"http://bogus.com" target=3D"_blank">bogus.com </a><br> > <a href=3D"http://250-nagasaki.bogus.com" target=3D"_blank">250-nagasa= ki.bogus.com</a> Hello<br> > [IPv6:2601:7:2380:XXXX:XXXX:XXXX:c1ae:7d73], pleased to meet you<br> > 250-ENHANCEDSTATUSCODES<br> > 250-PIPELINING<br> > 250-8BITMIME<br> > 250-SIZE<br> > 250-DSN<br> > 250-AUTH DIGEST-MD5 CRAM-MD5 LOGIN<br> > 250-STARTTLS<br> > 250-DELIVERBY<br> > 250 HELP<br> ><br> > that's essentially a downgrade attack on my ability to use encrypt= ion<br> > which seems to be in pretty poor taste frankly.<br> --<br> Mark Andrews, ISC<br> 1 Seymour St., Dundas Valley, NSW 2117, Australia<br> PHONE: +61 2 9871 4742=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0INTERNET: <a href=3D"mailto:marka@isc.org">marka@isc.org </a><br> </blockquote></div>

--bcaec517c6c01f783d0508e015a5-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

No. He is a comcast customer. And some third party wifi access point blocked his smtp submission over TLS by setting up an asa device to inspect 587 as well. On Nov 28, 2014 6:16 AM, "William Herrin" <bill@herrin.us> wrote:

On Thu, Nov 27, 2014 at 2:54 PM, joel jaeggli <joelja@bogus.com> wrote:

...

I don't see this in my home market, but I do see it in someone else's... I kind of expect this for port 25 but...

J@mb-aye:~$telnet 147.28.0.81 587 Trying 147.28.0.81... Connected to nagasaki.bogus.com. Escape character is '^]'. 220 nagasaki.bogus.com ESMTP Sendmail 8.14.9/8.14.9; Thu, 27 Nov 2014 19:17:44 GMT ehlo bogus.com 250-nagasaki.bogus.com Hello XXXXXXXXXXXXXXX.wa.comcast.net [XXX.XXX.XXX.XXX], pleased to meet you 250 ENHANCEDSTATUSCODES

J@mb-aye:~$telnet 2001:418:1::81 587 Trying 2001:418:1::81... Connected to nagasaki.bogus.com. Escape character is '^]'. 220 nagasaki.bogus.com ESMTP Sendmail 8.14.9/8.14.9; Thu, 27 Nov 2014 19:18:33 GMT ehlo bogus.com 250-nagasaki.bogus.com Hello [IPv6:2601:7:2380:XXXX:XXXX:XXXX:c1ae:7d73], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-8BITMIME 250-SIZE 250-DSN 250-AUTH DIGEST-MD5 CRAM-MD5 LOGIN 250-STARTTLS 250-DELIVERBY 250 HELP

that's essentially a downgrade attack on my ability to use encryption which seems to be in pretty poor taste frankly.

Hi Joel,

I'm not sure I follow your complaint here. Are you saying that Comcast or a Comcast customer in Washington state stripped the STARTTLS verb from the IPv4 port 587 SMTP submission connection between you and a third party?

Thanks, Bill Herrin

-- William Herrin ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/> May I solve your unusual networking challenges?

On Thu, Nov 27, 2014 at 9:51 PM, Jay Ashworth <jra@baylink.com> wrote:

----- Original Message -----

...

From: "William Herrin" <bill@herrin.us> I'm not sure I follow your complaint here. Are you saying that Comcast or a Comcast customer in Washington state stripped the STARTTLS verb from the IPv4 port 587 SMTP submission connection between you and a third party?

Yup; that's what he's saying. This was in the technical press earlier this week -- or the end of last.

Hi Jay, Seems to me that if an ISP is altering the contents of its users' packets (not just blocking them, altering them) then that ISP should be named and shamed, if not worse. Unless the customer contracted for special account type where that was a desired and intended feature, such behavior is inexcusable. If it's a customer of that ISP, on the other hand, then it's just the normal idiocy and paranoia, no different than the retarded behavior by amateur sysadmins that block all ICMP because they don't want to be pinged (see PMTUD and its effects on TCP). Anyway, I was curious which accusation was being leveled. Regards, Bill Herrin -- William Herrin ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/> May I solve your unusual networking challenges?

On 14-11-29 11:07, Sander Steffann wrote:

I am so glad that our Dutch net neutrality laws state that "providers of Internet access services may not hinder or delay any services or applications on the Internet" (unless [...], but those exceptions make sense)

However, in the case of SMTP, due to the amount of spam, most ISPs break "network neutrality" by blocking outbound port 25 for instance, and their SMTP servers will block much incoming emails (spam). However, SMTP is a layer or two above the network. But blocking port 25 is at the network level. I have seen wi-fi systems where you ask to connect to 20.21.22.23 port 25, and you get connected to 50.51.52.53 port 25. (the ISPs own SMTP server). I would rather they just block it than redirect you without warning to an SMTP server of their own where they can look and your outbound email, pretend to acccept it, and never deliver it.

In article <CAL9jLaY1q_RBkyB6kczKZUiFR5b1r3kuVz8WivWR0Rjj_oaGTg@mail.gmail.com> you write:

backing up a bit in the conversation, perhaps this is just in some regions of comcastlandia? I don't see this in Northern Virginia...

I don't see it in New Jersey, either. Is this a direct connection, or a coffee shop sharing a cable connection or something like that?

On 11/29/14 6:32 PM, Christopher Morrow wrote:

On Sat, Nov 29, 2014 at 3:09 PM, John Levine <johnl@iecc.com> wrote:

...

In article <CAL9jLaY1q_RBkyB6kczKZUiFR5b1r3kuVz8WivWR0Rjj_oaGTg@mail.gmail.com> you write:

...

backing up a bit in the conversation, perhaps this is just in some regions of comcastlandia? I don't see this in Northern Virginia...

I don't see it in New Jersey, either.

Is this a direct connection, or a coffee shop sharing a cable connection or something like that?

my test was a home consumer cable link, not business grade and not shared (more than cable is).

The phenomena I reported was observed on a consumer cable service (not my own). it is now no-longer in evidence with that same source ip. In answer an intermediate observation, the cpe and the devices on it are sufficiently well understood now to rule them out. from the mail servers vantage point... Nov 27 xxxxx nagasaki sm-mta[5698]: NOQUEUE: tcpwrappers ((reverse).wa.comcast.net, (ip) ) rejection given that the client gives up because it can't startssl and therefore won't attempt to auth. whereas a successful attempt with the same source ip is: Nov 26 xxxxx nagasaki sm-mta[397]: STARTTLS=server, relay=c-(reverse).wa.comcast.net [(ip)], version=TLSv1/SSLv3, verify=NOT, cipher=DHE-RSA-AES128-SHA, bits=128/128

n Sat, Nov 29, 2014 at 10:27 PM, joel jaeggli <joelja@bogus.com> wrote:

The phenomena I reported was observed on a consumer cable service (not my own). it is now no-longer in evidence with that same source ip. In answer an intermediate observation, the cpe and the devices on it are sufficiently well understood now to rule them out.

Hope it's not law enforcement tapping your line. They'd be damn fools to make themselves so easily detectable. -Bill -- William Herrin ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/> May I solve your unusual networking challenges?

On 11/29/14, 12:26 PM, "Jean-Francois Mezei" <jfmezei_nanog@vaxination.ca> wrote:

However, in the case of SMTP, due to the amount of spam, most ISPs break "network neutrality" by blocking outbound port 25 for instance

Whatever Net Neutrality may mean this week, it is usually intended to allow for reasonable network management practices, including preventing network abuse. In the case of port blocking, it is permissible provided it is disclosed transparently. - Jason

The STARTTLS filter was merely a tool used to divert and tap the traffic. It is the latter which is over the line. randy, on a teensy non-computer On Nov 29, 2014, at 15:17, John Levine <johnl@iecc.com> wrote:

...

i think of it as an intentional traffic hijack. i would be talking to a lawyer.

If the lawyer says anything other than that 47 USC 230(c)(2)(A) provides broad immunity for ISP content filtering, even if the filters sometimes screw up, you need a new lawyer.

Filtering STARTTLS on port 587 is pretty stupid, but not everything that's stupid is illegal.

R's, John

PS: I know enough technical people at Comcast that I would be extremely surprised if it were Comcast doing this. There's plenty not to like about the corporation, but the technical staff are quite competent.

On Dec 1, 2014, at 5:25 AM, Livingood, Jason <Jason_Livingood@cable.comcast.com> wrote:

On 11/29/14, 3:17 PM, "John Levine" <johnl@iecc.com> wrote:

...

PS: I know enough technical people at Comcast that I would be extremely surprised if it were Comcast doing this. There's plenty not to like about the corporation, but the technical staff are quite competent.

Thanks, John! I can tell folks here unequivocally that (1) the recent press article on STARTTLS re-writing did *not* involve Comcast and (2) Comcast does not engage in the claimed practice. In fact, weąre supporters and early deployers of STARTTLS on our own mail service.

I do not know how to explain the issue reported on this list. Absent a packet capture it is impossible for me to analyze this further. If anything, I could only imagine it was a misconfiguration someplace, but I have no idea where or in what network element thatąd even be possible. Iąm happy to work with anyone that has more info to try to troubleshoot this.

- Jason Livingood Comcast

I have encountered similar issues on some hotel networks. Usually, a well meaning, but severely misinformed hotel administrator decides that: 1. People don’t know what they’re doing and configure they’re laptops to use their [corporate|home|usual] mailserver even when they’re on the road, often without authentication. 2. Debugging people’s laptops for them takes a lot of time and reduces customer satisfaction. so 3. Let’s just redirect all port 25/587 to our own local SMTP proxy which can’t possibly support TLS because we don’t have all the right certificates (nor should we), so it won’t announce the STARTLES capability. I don’t know if that’s what happened in this case, because, as you say, without first-hand information and packet-captures, it’s impossible to tell, but I will say that if you intend to use TLS, make sure your MUA REQUIRES TLS, rather than preferring TLS when available (as is default on many MUAs, unfortunately). Owen

There’s a big difference between illegal and civil liability for breech of contract.

If I am paying someone for access to the internet, then I expect them not to modify, alter, rewrite, or otherwise interfere with my packets.

If they do so, they may not have violated 47 USC 230, but they have certainly failed to provide the service that I am paying for.

Uh huh. Please let us know the case number when you sue, so we can find out howthat pans out. By the way, I see you're a customer of Black Lotus. You might want to review sections 7 and 10 of the terms of service to which you've agreed: https://www.blacklotus.net/terms-of-service/ Your v6 traffic appears to arrive via a tunnel at HE. See sections 9 and 10 here, which you've also agreed to: http://www.he.net/tos.html R's, John