dslreports logo
 
    All Forums Hot Topics Gallery
spc
uniqs
1618

Rosie
@pacbell.net

Rosie to Rosie

Anon

to Rosie

List of domain names

The concensus from the various articles I've read seems to be that it's the AT&T spam filters that changed. If I understand correctly, then all AT&T domains would be affected by this change. Here is a list of AT&T domain names(not sure how current this is though):

bellsouth.net
worldnet.att.net
ameritech.net
att.net
flash.net
nvbell.net
pacbell.net
prodigy.net
sbcglobal.net
snet.net
wans.net
swbell.net

I am correct on this? (Again, not a techie -- just a struggling civilian here.)

nwrickert
Mod
join:2004-09-04
Geneva, IL

nwrickert

Mod

The concensus from the various articles I've read seems to be that it's the AT&T spam filters that changed. If I understand correctly, then all AT&T domains would be affected by this change.
I think bellsouth.net, att.net, worldnet.att.net are being handled by different servers, so I am not sure whether it applies to them.

NormanS
I gave her time to steal my mind away
MVM
join:2001-02-14
San Jose, CA
TP-Link TD-8616
Asus RT-AC66U B1
Netgear FR114P

NormanS to Rosie

MVM

to Rosie
said by Rosie :

Here is a list of AT&T domain names(not sure how current this is though):

bellsouth.net (MX server run by AT&T Worldnet Services)
worldnet.att.net (MX server run by AT&T Worldnet Services)
ameritech.net (MX server run by AT&T Internet Services)
att.net (MX server run by AT&T Worldnet Services)
flash.net (MX server run by AT&T Internet Services)
nvbell.net (MX server run by AT&T Internet Services)
pacbell.net (MX server run by AT&T Internet Services)
prodigy.net (MX server run by AT&T Internet Services)
sbcglobal.net (MX server run by AT&T Internet Services)
snet.net (MX server run by AT&T Internet Services)
wans.net (MX server run by AT&T Internet Services)
swbell.net (MX server run by AT&T Internet Services)

I am correct on this? (Again, not a techie -- just a struggling civilian here.)
AT&T Internet Services used to be SBC Internet Services (before SBC bought AT&T, and changed the corporate branding).

The 'bellsouth.net' domain was independent of anything SBC, or AT&T until AT&T bought Bellsouth.

I don't know that the 'worldnet.att.net' domain will ever be used with DSL service.
NormanS

NormanS to nwrickert

MVM

to nwrickert
said by nwrickert:

I think bellsouth.net, att.net, worldnet.att.net are being handled by different servers, so I am not sure whether it applies to them.
What I am seeing makes me think that AT&T Worldnet Services MX policies ('worldnet.att.net', att.net', and 'bellsouth.net') are now being applied to AT&T Internet Services MX servers.

Rosie
@pacbell.net

Rosie to NormanS

Anon

to NormanS
Thank you NormanS for the clarification on the AT&T domain names. I'm unclear about the "handed off" thing. Does that mean that the spam filters are applied at the AT&T MX server first such that some emails may be deleted or bounced back before they can get "handed off" to the Yahoo servers? Are the emails that get through being filtered again at Yahoo? I don't understand the terminology well enough to follow the explanations. I'll have to do some reading online in order to understand the messages in this thread. I was a comp. sci. major in college in the '80's -- 3 classes shy of a B.S. when I had to drop out for health reasons -- but I never actually worked in the field. The Internet was not in widespread use at that time, that I can recall.

nwrickert
Mod
join:2004-09-04
Geneva, IL

nwrickert

Mod

Does that mean that the spam filters are applied at the AT&T MX server first such that some emails may be deleted or bounced back before they can get "handed off" to the Yahoo servers?
That is my understanding of what is happening, based on the evidence thus far. Unfortunately AT&T has not given official information about this.
Are the emails that get through being filtered again at Yahoo?
Yes, but the Yahoo filtering mainly is for deciding what goes into your bulk folder.

And yes, things have changed a lot since the 80s.

NormanS
I gave her time to steal my mind away
MVM
join:2001-02-14
San Jose, CA
TP-Link TD-8616
Asus RT-AC66U B1
Netgear FR114P

NormanS to Rosie

MVM

to Rosie
Click for full size
Email messages in the Pegasus Mail client.
Click for full size
Email address in the Yahoo! Mail Options.
said by Rosie :

Thank you NormanS for the clarification on the AT&T domain names. I'm unclear about the "handed off" thing. Does that mean that the spam filters are applied at the AT&T MX server first such that some emails may be deleted or bounced back before they can get "handed off" to the Yahoo servers?
Based on some tests I did a while ago, the AT&T MX servers do some basic filtering by DNSBL, and similar criteria. Email will either be accepted, or rejected a this point. Rejected email results in a "bounce" generated by the sending relay client (if that relay client is a spamming 'bot, no "bounce" is generated). Accepted email is forwarded to Yahoo! Mail Delivery Agents for placement in the user's mailbox.
Are the emails that get through being filtered again at Yahoo?
Yes. The Yahoo! MDAs provide additional filtering based on the criteria established for SpamGuard. Nearly as I can tell, no "bounces" are generated at this point; rather, email is either routed to the Inbox, or the Bulk folder. This is actually a "Good Thing®" because a "bounce" generated at this point could only go to the Return_Path email address; in spam this is forged, or fake, about 99% of the time. This would result in "backscatter": Sending "bounces" to uninvolved parties.

Just an example of what you should see in this process:
Received: from 207.115.36.38  (EHLO nlpi009.prodigy.net) (207.115.36.38)
  by mta148.sbc.mail.mud.yahoo.com with SMTP; Wed, 02 Apr 2008 07:53:46 -0700
X-Originating-IP: [65.55.175.211]
Received: from blu139-omc3-s11.blu139.hotmail.com (blu139-omc3-s11.blu139.hotmail.com [65.55.175.211])
by nlpi009.prodigy.net (8.13.8 inb regex/8.13.8) with ESMTP id m32Erjfb014056
for <%User_ID%@pacbell.net>; Wed, 2 Apr 2008 09:53:45 -0500
Received: from BLU110-DS2 ([65.55.162.188]) by blu139-omc3-s11.blu139.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959);
 Wed, 2 Apr 2008 07:53:45 -0700
Subject: [TEST] Routing of email through at&t Yahoo! HSI service
 
The "Received" line at the bottom of the list is reporting my client connection (Windows Live Mail) to a Windows Live Mail account.

The "Received" line in the middle is the ATTIS MX server for the 'pacbell.net' domain accepting the email from the 'live.com' SMTP relay agent. This is where the initial filtering will take place; and the "accept/reject" decision would be made.

The "Received" line at the top is the Yahoo! MDA for this 'pacbell.net' account. This is where the filtering decision for "Inbox/Bulk" will take place.

By comparison, here is a straight Yahoo! email address. These headers from a 'yahoo.com' email address added to that 'pacbell.net' account as an "Extra" email address through the Mail Options:
Received: from 65.55.175.212  (EHLO blu139-omc3-s12.blu139.hotmail.com) (65.55.175.212)
  by mta462.mail.mud.yahoo.com with SMTP; Wed, 02 Apr 2008 08:35:29 -0700
Received: from BLU110-DS3 ([65.55.162.187]) by blu139-omc3-s12.blu139.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959);
 Wed, 2 Apr 2008 08:31:36 -0700
Subject: [TEST] Extra email address
 
This was picked up by the same account. You will see that this time the email goes straight to the Yahoo! server, bypassing the ATTIS server.

The screen shots show both email messages in the client folder, and the Yahoo! Mail Options screen where the extra accounts are set up.

Rosie
@pacbell.net

Rosie

Anon

AT&T and Yahoo servers

Wow, NormanS, thank you so much for the very detailed answer, with screen shots and all. I skimmed it for now and will study it later when I have the time. Very enlightening, thank you.

David
Premium Member
join:2002-05-30
Granite City, IL

David

Premium Member

Click for full size
err553.pdf
845,274 bytes
For those that are needing it, here is the err553 document and details.

justbits
DSL is dead. Long live DSL!
Premium Member
join:2003-01-08
Chicago, IL

2 edits

2 recommendations

justbits

Premium Member

Email domains w/Disposable or Wildcard Addresses now a PITA

I'd like to point out that the error 553 document and »help.yahoo.com/l/us/yaho ··· -07.html URL describe a procedure that only works with the "Classic Mail" interface. It also fails to work with email domains that provide disposable/wildcard addresses.

I run my own email server. I have my own version of Disposable Email Addresses that works similar to how wildcard email domains work. The "error 553" change now requires that I "Verify" every single unique email address that I expect to originate email from by going though a configuration page on the AT+T Yahoo Email configuration web site. That is going to be nearly impossible to automate with my email domain(s) that provide wildcard and/or disposable email addresses.

What I'd like to propose is that domains can be added and validated such that *@mydomain.com is acceptable not just oneaddress@mydomain.com. (Where "*" represents that any email address user is valid.)

Therefore, I propose that on the "Step 2: Enter Email Address" page, "Name:" be allowed to be "postmaster@mydomain.com" and "Email:" be allowed to be "*@mydomain.com" so that postmaster@mydomain.com is responsible for all email originated as *@mydomain.com for my AT+T Yahoo email credentials. The "verification" email would be sent to postmaster@mydomain.com. If AT+T Yahoo would require me to implement DomainKeys or DKIM, I'd be glad to enter that information as a part of the configuration process for getting wildcard domains approved.

Can you help get this change to allow wildcard/disposable email domains? Whose cage should I start rattling?

NormanS
I gave her time to steal my mind away
MVM
join:2001-02-14
San Jose, CA
TP-Link TD-8616
Asus RT-AC66U B1
Netgear FR114P

1 recommendation

NormanS

MVM

said by justbits:

Therefore, I propose that on the "Step 2: Enter Email Address" page, "Name:" be allowed to be "postmaster@mydomain.com" and "Email:" be allowed to be "*@mydomain.com" so that postmaster@mydomain.com is responsible for all email originated as *@mydomain.com for my AT+T Yahoo email credentials. The "verification" email would be sent to postmaster@mydomain.com. If AT+T Yahoo would require me to implement DomainKeys or DKIM, I'd be glad to enter that information as a part of the configuration process for getting wildcard domains approved.
I will second this proposal.
justmb
join:2005-08-19
Naperville, IL

justmb to justbits

Member

to justbits
I vote for this too!

I need disposable address support!

David
Premium Member
join:2002-05-30
Granite City, IL

David

Premium Member

I turned your request over to a few friends and from what I got back it only accepts individual addresses at this time not domains. Basically from what I got Yahoo! is not budging on the issue. Apparently it was covered prior to you guys thinking it.

justbits
DSL is dead. Long live DSL!
Premium Member
join:2003-01-08
Chicago, IL

justbits

Premium Member

This is a great way for AT+T to lose some of the more advanced customers that run services from their home DSL line.

With this change, the primary alternatives are:
* switch to a different provider that provides a static IP address. (For me, SpeakEasy, Covad, Lightning Bolt DSL, maybe others.)
* switch to a business package that has a static IP address.
* find a third party to pay that provides wildcard email domain address forwarding.

Unless this is a marketing decision to get people running email servers to switch to business accounts (non-RBLed static IPs), I don't see how preventing wildcard email domains is a spam or security threat to AT+T/Yahoo. I can see how this makes complete sense for "free" Yahoo! accounts where anybody can create an account, abuse it, and leave it. However, AT+T/Yahoo's service is directly tied to monetary payments and a billing system that can physically locate the person responsible for a particular email account.

If they're worried on the technical side that someone may decide that they want to send as *@gmail.com, I can understand where that trust issue comes from. Therefore, I propose doing something similar to what Google Apps requires. Require that the customer provide a DNS record that AT+T Yahoo generates, and can thus verify by a DNS lookup.

Google does domain verification by requiring the customer to create a new DNS CNAME record, such as:
googlefffffafbfcfdfefg.mydomain.com. CNAME google.com.
By having the customer modify their DNS domain information, this provides sufficient proof that the requester owns that particular domain and has the capability to edit the DNS records for that domain.

I understand that adding a DNS verification method to validate wildcarded email domains for email verification could require significant work on AT+T/Yahoo's side of the world and that it probably can't be done overnight. But, it's a solution to a problem that they're otherwise ignoring that could result in an exodus of a certain kind of AT+T/Yahoo customer.

Another alternative that AT+T could provide to solve my problem is single static IP addresses. I'd be happy to pay $5/month (maybe $10/month) to get a single static IP address that is NOT listed in any RBL (realtime black list). As I understand it, single static IPs can be done with changes to PPPoE Authentication on the customer side (@static.sbcglobal.net?) and configuration on the Redback(s). I'm sure there are several blocks of addresses out there that AT+T hasn't registered with RBLs as dynamic IP addresses.