NormanS
Premium,MVM
join:2001-02-14
San Jose, CA
 ·Pacific Bell - SBC
| reply to Rosie
Re: List of domain names
Email messages in the Pegasus Mail client. | 
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:
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:
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.
--
Norman
~Oh Lord, why have you come
~To Konnyu, with the Lion and the Drum |
|
Rosie
@pacbell.net | 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
Last man standing
Premium,VIP
join:2002-05-30
Granite City, IL
clubs:
 ·magicjack.com
·AT&T Midwest
| For those that are needing it, here is the err553 document and details. |
|
justbits
More fiber than ATT can handle
Premium
join:2003-01-08
Chicago, IL
·AT&T Midwest
·AT&T Yahoo
edit:
April 3rd, @10:48AM
| 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/yahoo/mail/o···-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
Premium,MVM
join:2001-02-14
San Jose, CA
·Pacific Bell - SBC
| 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.
--
Norman
~Oh Lord, why have you come
~To Konnyu, with the Lion and the Drum |
|
justmb
join:2005-08-19
Naperville, IL | reply to justbits
I vote for this too!
I need disposable address support! |
|
David
Last man standing
Premium,VIP
join:2002-05-30
Granite City, IL
clubs:
·magicjack.com
·AT&T Midwest
| 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
More fiber than ATT can handle
Premium
join:2003-01-08
Chicago, IL
·AT&T Midwest
·AT&T Yahoo
| 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. |
|
