Verizon.net Finally Moving Email To Port 587 195
The Washington Post's Security Fix blog is reporting that Verizon, long identified as the largest ISP source of spam, is moving to require use of the submission port, 587, in outbound mail — and thus to require authentication. While spammers may still be able to relay spam through zombies in Verizon's network, if the victims let their mail clients remember their authentication credentials, at least the zombies will be easily identifiable. Verizon pledges to clean up their zombie problem quickly. We'll see.
try PRQ.se (Score:2, Informative)
I've been routing my traffic thru their traffic for a few years now, they're not limiting anyone and keep great privacy. what i heard their tunnel service will be open for new customers in a few days again so now is a great time.
What's this "finally" shit? (Score:5, Informative)
You can set up port 25 SMTP to require authentication for relay purposes, without having to configure end user's machines for another port.
You can, but it's hokey (Score:3, Informative)
Yeah, it's possible to do authentication on Port 25, but it's generally hokey and often broke things when people did it, and left passwords in the clear for eavesdroppers - 587 is a cleaner and more standardized solution. I remember having to configure Eudora for receive-before-send when my email provider was trying that approach...
great, only 7 years late (Score:5, Informative)
Verizon has been an epic sewer network for years, and has ignored their spam problem for years. If they want to clean up now (or make a lame attempt to clean up, as most telco's do), fine. It just means less work for iptables at my end.
For those who are sick of Verizon's bullshit, here's my list (no promises this is complete, but it should have most of em) of Verizon's ip blocks.
206.46.0.0/16
66.12.0.0/14
207.68.0.0/17
71.96.0.0/11
72.64.0.0/11
72.42.0.0/18
71.160.0.0/15
71.162.0.0/16
96.224.0.0/11
98.108.0.0/14
98.112.0.0/13
68.160.0.0/14
162.84.0.0/16
162.83.0.0/16
151.204.0.0/15
138.88.0.0/21
66.171.0.0/16
66.14.128.0/17
151.201.0.0/16
138.89.0.0/16
141.149.0.0/16
141.150.0.0/15
141.152.0.0/14
141.156.0.0/15
141.158.0.0/16
68.160.192.0/18
68.161.192.0/18
66.14.0.0/17
151.196.0.0/14
151.200.0.0/14
151.204.0.0/15
129.44.0.0/16
138.88.0.0/16
64.222.0.0/15
68.236.0.0/14
70.104.0.0/13
70.16.0.0/13
71.96.0.0/11
209.158.0.0/16
209.159.0.0/19
71.160.0.0/11
173.64.0.0/12
70.192.0.0/11
66.174.0.0/16
75.224.0.0/12
75.240.0.0/13
75.192.0.0/10
97.0.0.0/10
Re:Finally, Verizon, Finally!! (Score:5, Informative)
I send out a newsletter with about 250 subscribers. After talking with SORBS, I contacted Verizon and found out that, even though we signed up for Verizon Business, they limit the amount of email I can send a week to 500 messages.
Verizon Business accounts assume that you will probably be running a business, and have your own domain.
If you do things this more professional way, there are no limits with Verizon DSL or FiOS (other than the speed you pay for being a "limit").
Re:Do zombies even use ISP mail servers? (Score:3, Informative)
The first scenario that comes to mind is that the next generation of bot-ware will listen to your outgoing email traffic and learn your password then configure itself to send email based on that information. Then once again, the problem returns.
The advantage in this instance is that the ISP can easily identify (because the zombie used the user/pass) who has been zombified and inform the customer to get their machine disinfected.
Re:What ever happened to SSL and port 465? (Score:5, Informative)
Port 587 was allocated by IANA and is documented by the IETF in RFC 2476, and the STARTTLS capability is documented in RFC 2487. It is not clear from the article whether Verizon is going to require STARTTLS or not. They may require STARTTLS for all mail on port 587 if they so choose.
I assume that the "full-on SSL" that you would prefer refers to the non-standard port 465 ("SMTPs"). That port was chosen arbitrarily by Microsoft, has not been standardized by any common standards body, and was previously already allocated to "URL Rendesvous Directory for SSM".
Why perpetuate non-standards when there are established standards which have the same functionality?
hehe (Score:4, Informative)
I just reread your link. In it DJB explicitly advises against running authentication on port 25. In fact, for security reasons, he wrote two separate programs, qmail-smptd and ofmipd, to keep the tasks of relaying authenticated email and accepting mail for local delivery as removed from one another as possible.
He defends the idea of separating these two tasks, not only to separate ports but separate programs, on this thread [imc.org] on the IETF-SUBMIT mailing list.
So, yeah, his complaint against port 587 was simply that if you can't implement the SUBMIT standard correctly (which according to him noone can), you should use a different port then the one specified in that standard. The rest of the world doesn't care, because it sees all the various authentication methods (including SUBMIT) as extensions to SMTP, and not as a different protocol (OFMIP as DJB calls them collectively), and have no qualms running a standard (non-SUBMIT compliant) SMTP server on port 587.
Re:Finally, Verizon, Finally!! (Score:2, Informative)
Re:Finally, Verizon, Finally!! (Score:4, Informative)
Guess what, "The CAN-SPAM Act of 2003 (Controlling the Assault of Non-Solicited Pornography and Marketing Act) establishes requirements for those who send commercial email"
Parent did not specify that it was commercial email and "newsletter" indicates that it likely is not. Even if they were of a commercial nature they would likely be exempted under the CAN-SPAM act as they would qualify as "relationship" messages [cornell.edu].
Re:Finally, Verizon, Finally!! (Score:2, Informative)
A number of admins I know block all email originating from Constant Contact as UCE. That's the problem with a lot of 'email marketing firms' - they take legit users along with spammers or quasi-spammers. Unless you decide to truly take control of your email by operating your own mail server, you run the risk of getting caught using an entity that gets blocked for their other clients' activities.