Verizon Email Restrictions

CodeMonkey5 writes: "The following excerpt is from a Verizon email sent to all Verizon customers regarding the use of their SMTP servers. The gist of it is that if you are using an email address other than that of Verizon in the 'From' field, you cannot use their SMTP servers. '...If you are sending email using an email address other than one provided by Verizon Online, this message affects you. Effective, August 8, 2001, you will no longer be able to send email from any email address other than the one provided by Verizon Online (this includes privately branded domains and secondary ISP accounts). We are taking this action as a result of our continuing efforts to improve the quality and reliability of Verizon's mail system and is one of several steps to help reduce spam. The effect of this change is that Verizon Online email will no longer support sending email from other ISP accounts or privately branded domains that are not hosted by Verizon Online ...'"

Comments

Re:Uhhh.. how's this a problem?

[Genom]

This isn't really a relaying issue, though - they're just disguising it as one.

The real issue is that people are ordering Verizon, and either hosting their own domains (over DSL, with a static IP), or using other email addresses (such as domains they may have forwarding to their Verizon account, or alternate ISP accounts with better email packages/controls) - and Verizon doesn't like that.

The dream of all big consumer-oriented corporations is a huge closed-doors community, where once you're a customer, you have to do everything through them. That's what Verizon wants.

They want to guarantee that if you're a Verizon customer, that you USE your Verizon-branded email. That makes your address a "verified good" address, that they can then put on a list, along with your name, and any other personal information that you've given them, and sell to other companies.

They want to make sure that when you go for a domain for yourself, or your business, that you have NO CHOICE but to have Verizon host it - otherwise yo won't be able to take advantage of it through your existing Verizon 'net access account.

Were I a Verizon Online customer, which I'm not, I would be furious - even if this policy didn't affect me *now* - as it might in the future.

I'm very glad I went with Speakeasy for my DSL line, and not Verizon. It will be a sad day when Speakeasy implements any kind of policy like this.

As for options existing Verizon customers have - the best option would, of course, be to cancel your Verizon account, tell them the reason, and go with a competitor who has a saner policy. Barring that - is Verizon blocking SMTP sends from DSL customers running their own SMTP servers on static IPs? If not, it might not be a bad idea to pick up a cheap linux box and run Sendmail/Postfix/Exim/Qmail to handle external accounts.

Re:Just use your own relay.

[Sethb]

iMac: $999
OS X: Included with the iMac
Sendmail: Free

Factual Slashdot Post: Priceless
---

From us that host domains

[doon]

We are a small ISP and host domains and for some of the business in the area. We recently had a couple of them come to us with this problem. We don't want to install pop before smtp at this moment as we are rebuilding our datacenter. Since verizon dsl doesn't even offer static ip's to it's customers, we have 2 choices, tell the customer to use their verizon mail address and their @domainname address in the reply to field. Or us open up our mail server to accept mail from a /22. When talking to verizon they told our customer that they should just host with them. Spam my ass. -doon

Re:From us that host domains

[slamb]

You're missing an option: SASL authentication. My Postfix mailserver is configured to use this and it works out fairly well. The major clients (Outlook, etc) seem to have support for it.

It's configured like this:

smtp_client_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_unknown_client,
reject_maps_rbl,
permit
smtpd_recipient_restrictions =
reject_unknown_recipient_domain,
check_recipient_access
hash:/usr/local/etc/postfix/access,
permit_mynetworks,
permit_sasl_authenticated,
permit_auth_destination,
reject

The client section allows my networks (you'd put in localhost and your dialup links) and SASL authenticated people, without checking DNS or the RBL (which is important if you are using the DUL; otherwise their machine may be listed and denied).

The recipient section allows SASL-authenticated people to send to addresses other than the auth_destination ones - in other words, to relay.

So, unless I'm missing something (like a big mail client that doesn't support SASL at all), there's a pretty good way for you and people like you to still provide supplementary addresses. And I think this move really will cut down on spam.

Shhh. It's a secret

[Fapestniegd]

I geuss I'll have to use the secret Reply-to: header.

Annoying, but a reasonable policy to enforce.

[Nonesuch]

This isn't really a question of 'relaying' mail through their servers, it's more a question of preventing users on Verizon's network from forging the SMTP 'From' address, when sending outgoing mail through Verizon's mail hosts. This is a reasonable policy to enforce.

It prevents forgery, but also prevents users from using other legitimate email addresses as the sender- since there is no way for Verizon to know an address is legitimate, except for the one address they've assigned to the customer.

There's another tactic that some ISPs are using to prevent spamming- blocking or redirecting end-user connections to any port 25 at any remote host except for the ISPs own mail servers. If Verizon were to combine their anti-forgery rule with a 'you must use our mail hosts' rule, that would be a serious inconvenience to legitimate users.

There is a solution.

If you absolutely must send mail with the 'From' being a domain other than your ISP, see if the actual owner of the domain will set up a POPmail server with 'XTEND XMIT' support, allowing you to send out your mail from an authenticated POP session. Note that this is entirely different from the 'pre-authenticating SMTP relay access' technique that was found to be buggy recently.

Non-Issue

[bill.sheehan]

I'm a Verizon DSL customer, and this is an utter non-issue. For ~ $25/year, I have my own domain through a DDNS provider and I just run my own mail server. No sweat, and a good deal more reliable than Verizon's has been over the past year.

For the students who are suffering because they can no longer claim to be @foobar.edu when sending through @verizon.net, may I suggest a quick look at RFC2822? Mail programs don't respond to the "From" address, they respond to the "Reply-To" address.

The early bird gets the worm, but the second mouse gets the cheese.

Real motive a disincentive from changing ISPs?

[sanemind]

Although in principal I'm all for reducing spam, refusing paying customers the ability to send mail that is returnable to the account they choose would be very annoying. Most people don't like to use their ISP provided email addr because if people come to know them by that addr, [store it in their address book, rolodex, etc], then the customer is more locked into not switching ISP's because they would then lose that address.

They are their own servers and all, they can provide whatever level and type of, cough, service, they want to. If I was using verizon I would consider strongly switching ISP's right away.

Also, there is the question of whether or not it is really necessary to use them as a mail gateway. One can always run one's own invocation of sendmail, and it would happily squirt off mail with any return address you wanted. That is, unless they have transparently proxied port 25, and put this additional restriction on it. Course, that wouldn't be so transparent a proxy anymore, would it.

I'll have to wait until I know more, but I really don't like any additional restrictions on use. Besides, spam really isn't much of a problem to me anyway. Just use seperate addresses for different classes of mail. Keep the spam coming to one or two, and have others for private and personal contacts.

---

WHOAH...

[sourcehunter]

Wait a dern minute here...

I can understand blocking outgoing port 25 on your network except for your mail server and thus assuring that all mail is routed through the ISP's mail server - Mindspring/Earthlink has been doing this for quite a while! But not relaying mail for your local users (regardless of from address) breaks one of the core reasons for having LOCAL mail servers. What the hell else are people going to do? Most third partys' mail servers are locked down to allow local relay only (as well they should be!). Yeah there are a few open relays out there, but everyone won't be able to find one. I for one won't be opening up my server!

Here's what I see happening:
This will actually increase Verizon Online's network's contribution to spam...

1. Verizon blocks their users from using their mail servers for foo@bar.com accounts
2. Many of the more savvy users start their own mail servers on verizon's network to act as a local relay.
3. Some of these people aren't going to be savvy enough and some of these servers will not be configured correctly such that they are open relays (not hard AT ALL to do)
4. Some spammers find these open relays
5. Verizon's network is now contributing to the spam

Basically, what this tells me is that they are too lazy to police their own users by dealing with spammers when they occur and instead have opted to just say "It isn't us! We're secured!"

Not sure what to think

[daniel_isaacs]

Obviously this is not a kosher thing to do with regards to established norms of Internet community and openess. But, this ain't 1993. I seriously doubt how much spam this will prevent.

But, in the end, the servers ARE theirs. If they don't want to share, or if they want to limit thier customers abilities, we can do thing the Capitalist way. Not buy thier service, and use other smtp servers. I've had RoadRunner for over a year now, and haven't even setup my *@rr.com accounts. I use thier DNS, but that's it. Perhaps I don't fully understand the implication of Verizon (Sprint) doing this, but I don't really see how it will amount to a hill of beans.