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.
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.
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?
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.
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.
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.
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.
backing up a bit in the conversation, perhaps this is just in some
regions of comcastlandia? I don't see this in Northern Virginia...
$ openssl s_client -starttls smtp -connect my-mailserver.net:587
CONNECTED(00000003)
depth=0 description = kVjtrCL8rUdvd00q, C = US, CN = my-mailserver.net, emailAddress = my-emailaddrss.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 description = kVjtrCL8rUdvd00q, C = US, CN = my-mailsever.net,
emailAddress = my-emailaddress.com
verify error:num=27:certificate not trusted
verify return:1
depth=0 description = kVjtrCL8rUdvd00q, C = US, CN = my-mailserver.net, emailAddress = my-emailaddress.com
verify error:num=21:unable to verify the first certificate
verify return:1
...
Certificate chain
0 s:/description=kVjtrCL8rUdvd00q/C=US/CN=my-mailserver.net/emailAddress=y-emailaddress.com
i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate
Signing/CN=StartCom Class 1 Primary Intermediate Server CA
...
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: FC3E47AF2A2A96BF6DE6E11F96B02A0C41A6542864271F2901F09594DE9A48FA
Session-ID-ctx:
Master-Key:
BE7FB76EF5C0A9BA507B175026F73E67080D6442201FDF28F536FA38197A9B1353D644EEAF8D0D264328F94B2EF5742C
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1417286582
Timeout : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)
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.
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.