AT&T has a Postmaster site, but it doesn't contain a comprehensive list of their inbound email domains, so I thought it might be useful to put something together and share it with the world.
Here's all the AT&T consumer email domains that I know of:
pacbell.net
bellsouth.net
sbcglobal.net
ameritech.net
att.net
flash.net
nvbell.net
prodigy.net
snet.net
swbell.net
wans.net
Note that AT&T users either do or used to read mail through the Yahoo! Mail user interface, which means that some Yahoo! Mail filters could come into play when sending to AT&T users. However, AT&T runs their own inbound email servers, with their own filters and their own blocking, so it's very possible to be specifically blocked by AT&T.
Special thanks to reader Laurence Marks, who provided most of this list in a past comment, and I only now realized it might be helpful to all if we broke it out to its own post. Thanks!
Are any domains missing? Leave a comment with corrections, feedback or questions.
A spam score of 33.8!
Since I've enabled a "reject" DMARC policy on my domains, I've been reviewing the various failure reports that come in to see what crazy spam those crazy spammers might try to send. Amazingly, they are willing to try to send some really bad stuff to see if it gets through.
The email problem no one is talking about: mistaken identity
Mashable's Chris Taylor talks about the problem of misdirected emails. A good read and it helps to expose a real issue that I don't think many people stop and consider.
I'll add my own questions here. What if, because of this, a sender is exposing PII (personally identifiable information) to a random third party? Couldn't that lead to some sort of legal liability at some point? How does a recipient stop emails like that? Are you, as a sender, putting a "this is not me" link in your transactional messages?
I have a bunch of spamtrap domains. One of them is a typo variation of a very popular ISP domain. The number of misdirected order confirmations and password reset requests it gets is ... staggering. If I was a bad guy, think of all the bad things I could do with that information being fire-hosed directly to me. I could probably take over hundreds of Instagram accounts. I could probably cancel or redirect orders from online stores. Or worse.
More reasons why you can't just assume that any email address given to you is correct.
I'll add my own questions here. What if, because of this, a sender is exposing PII (personally identifiable information) to a random third party? Couldn't that lead to some sort of legal liability at some point? How does a recipient stop emails like that? Are you, as a sender, putting a "this is not me" link in your transactional messages?
I have a bunch of spamtrap domains. One of them is a typo variation of a very popular ISP domain. The number of misdirected order confirmations and password reset requests it gets is ... staggering. If I was a bad guy, think of all the bad things I could do with that information being fire-hosed directly to me. I could probably take over hundreds of Instagram accounts. I could probably cancel or redirect orders from online stores. Or worse.
More reasons why you can't just assume that any email address given to you is correct.
XNND.com is 11 years old today
I've long had a little banner at the bottom of my xnnd.com DNS tools site that says "since 2008" but it looks like I'm going to have to change that. Looking through my notes, the site actually launched eleven years ago today!
XNND exists because back then there was a commonly used "DNS stuff" site out there that I felt like was trying to scare people into buying services from them and I didn't like it, so I decided to put together my own little DNS lookup site that was bullshit-free and simple to use. I registered the domain on June 14th, 2007 and then launched the site on June 17th.
I redesigned the site recently to make it a bit easier on the eyes. And yep, that's all done with HTML tables, like it was built in 1997 instead of 2007 or 2018.
I've had to erase and reload the server so many times, I don't even know how much traffic it really gets. But it seems to be a busy little guy, and I hope folks continue to find it useful.
I've got setting up a server to be XNND.com down to a science. Every time there's any sort of hint of a security or hardware issue, I just nuke the whole thing and populate a new installation. Sometimes servers crash, sometimes weird stuff happens, and I've even had one hosting provider just up and disappear from the internet.
Special thanks to Don Berryman and Steve Atkins who were very helpful with bits of code and hosting when it was first getting up and running.
XNND exists because back then there was a commonly used "DNS stuff" site out there that I felt like was trying to scare people into buying services from them and I didn't like it, so I decided to put together my own little DNS lookup site that was bullshit-free and simple to use. I registered the domain on June 14th, 2007 and then launched the site on June 17th.
I redesigned the site recently to make it a bit easier on the eyes. And yep, that's all done with HTML tables, like it was built in 1997 instead of 2007 or 2018.
I've had to erase and reload the server so many times, I don't even know how much traffic it really gets. But it seems to be a busy little guy, and I hope folks continue to find it useful.
I've got setting up a server to be XNND.com down to a science. Every time there's any sort of hint of a security or hardware issue, I just nuke the whole thing and populate a new installation. Sometimes servers crash, sometimes weird stuff happens, and I've even had one hosting provider just up and disappear from the internet.
Special thanks to Don Berryman and Steve Atkins who were very helpful with bits of code and hosting when it was first getting up and running.
Revisiting Spam, the Documentary
Remember this blast from the past? Back in 2007, email expert John Levine sat down with Canada's CBC News to be interviewed for what became "Spam, the Documentary." It wasn't widely available in the US then, but appears to be viewable on YouTube right now.
How much has spam changed since 2007?
How much has spam changed since 2007?
Gmail's Promotional tab: How to escape
How do I keep my email messages out of Gmail's Promotional tab? This is a common question lately. Is there one common answer? Ask six different people, and you'll get six different answers. And I'm not sure which answer is the best one, so I'll collect them here and we can all learn together.
The big red warning box of doom
Here's the updated DOOM WARNING that appears on a suspicious message in the new Gmail user interface. But why, I ask, would it appear on this particular message that I received? The message in question fully authenticates, it was sent from a reputable ISP, and it was an email message from my city government. It's an email list that I've opted-in to.
They use an ESP that uses a group of IP addresses to be shared among all clients, so I assume what happened is that the shared reputation has gotten dinged by some bad sender doing something wrong sometime prior to this send. It sucks, though, because this message isn't actually dangerous and the warning is probably going to freak people out.
Locking down your unused domains
Here's a neat DMARC trick that I would have implemented sooner, had I read MAAWG's "Best Practices for Parked Domains" document a little closer back when it came out back in late 2015. But back then, I wasn't as DMARC savvy as I was now.
Anyway, the trick is this: If you have a domain that doesn't send mail, here's how you lock it down -- publish DNS records -- that tell the big ISPs that any mail pretending to be from that domain should be rejected, because it is illegitimate.
To do that, you'll want to configure two DNS records for your domain.
First, create an SPF record for your domain. This is a TXT record that goes at the top level of your domain. In it, paste this text: "v=spf1 -all" (without the quotes). A domain that sent email would use this record to specify what IP addresses are allowed to send mail on this domain's behalf. Since there are none, we're leaving it entry. The "dash all" directive at the end tells ISPs to treat mail from IP addresses not listed here as very suspicious. I call this SPF lockdown and I've talked about it before.
Second, create a DMARC record for your domain. This is a TXT record as well, called _dmarc and when you create it, paste the following text: "v=DMARC1; p=reject;" (without the quotes). This tells ISPs to reject unauthenticated mail purporting to be from your domain name. Most people, when setting up a comprehensive DMARC record, set up reporting addresses to receive failure reports, and include that information in the DMARC record. You don't have to do that, though. Save yourself the time and don't worry about that. (Want to see an example DMARC record? Here's mine.)
The DMARC record is the new part of the trick, and it's an important bit.
Together, with those two DNS records, you're pretty well covered to tell ISPs that this domain doesn't send any mail (or technically, that any forged mail purporting to be from this domain should be rejected -- and since you send no legitimate mail from this domain, any mail seen at all is going to be forged, and therefore, rejected).
Spammers have a long history of forging domain names in spam. This simple little process makes your unused domain name much less useful to spammers. If they spoof that domain name in spam, most of that mail will get rejected. Smart spammers might even check to see if a domain publishes a "reject" DMARC policy and avoid ones that do.
Anyway, the trick is this: If you have a domain that doesn't send mail, here's how you lock it down -- publish DNS records -- that tell the big ISPs that any mail pretending to be from that domain should be rejected, because it is illegitimate.
To do that, you'll want to configure two DNS records for your domain.
First, create an SPF record for your domain. This is a TXT record that goes at the top level of your domain. In it, paste this text: "v=spf1 -all" (without the quotes). A domain that sent email would use this record to specify what IP addresses are allowed to send mail on this domain's behalf. Since there are none, we're leaving it entry. The "dash all" directive at the end tells ISPs to treat mail from IP addresses not listed here as very suspicious. I call this SPF lockdown and I've talked about it before.
Second, create a DMARC record for your domain. This is a TXT record as well, called _dmarc and when you create it, paste the following text: "v=DMARC1; p=reject;" (without the quotes). This tells ISPs to reject unauthenticated mail purporting to be from your domain name. Most people, when setting up a comprehensive DMARC record, set up reporting addresses to receive failure reports, and include that information in the DMARC record. You don't have to do that, though. Save yourself the time and don't worry about that. (Want to see an example DMARC record? Here's mine.)
The DMARC record is the new part of the trick, and it's an important bit.
Together, with those two DNS records, you're pretty well covered to tell ISPs that this domain doesn't send any mail (or technically, that any forged mail purporting to be from this domain should be rejected -- and since you send no legitimate mail from this domain, any mail seen at all is going to be forged, and therefore, rejected).
Spammers have a long history of forging domain names in spam. This simple little process makes your unused domain name much less useful to spammers. If they spoof that domain name in spam, most of that mail will get rejected. Smart spammers might even check to see if a domain publishes a "reject" DMARC policy and avoid ones that do.
Subscribe to:
Posts (Atom)