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.
This one email message I received a DMARC failure report about today came with a SpamAssassin score of 33.8. Most often, a SpamAssassin score of 5 or greater is considered spammy. And I don't think I've seen a SpamAssassin score above 12 in a long time. This bad guy is sending pill-selling spam while pretending to be from a domain he doesn't own (one that's locked down with DMARC), linking to blacklisted domains and sending from an IP address that's listed on a bunch of different blacklists. It surely doesn't seem like a recipe for success. Why even bother to keep spewing garbage when nobody is going to receive it?
Here's the different SpamAssassin rules that ONE SINGLE MESSAGE triggered:
1.9 URIBL_ABUSE_SURBL Contains an URL listed in the ABUSE SURBL blocklist
2.5 URIBL_DBL_SPAM Contains a spam URL listed in the Spamhaus DBL blocklist
1.2 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net
3.0 RCVD_IN_MSPIKE_L3 RBL: Low reputation (-3)
1.3 RCVD_IN_RP_RNBL RBL: Relay in RNBL, https://senderscore.org/blacklistlookup/
0.7 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
2.7 RCVD_IN_PSBL RBL: Received via a relay in PSBL
0.1 URIBL_SBL_A Contains URL's A record listed in the Spamhaus SBL blocklist
0.6 URIBL_SBL Contains an URL's NS IP listed in the Spamhaus SBL blocklist
0.0 TVD_RCVD_IP4 Message was received from an IPv4 address
0.0 TVD_RCVD_IP Message was received from an IP address
2.3 SUBJECT_DRUG_GAP_L Subject contains a gappy version of 'levitra'
0.6 HK_RANDOM_ENVFROM Envelope sender username looks random
1.2 RCVD_HELO_IP_MISMATCH Received: HELO and IP do not match, but should
0.9 RCVD_NUMERIC_HELO Received: contains an IP address used for HELO
0.9 SPF_FAIL SPF: sender does not match SPF record (fail)
0.0 HTML_IMAGE_RATIO_08 BODY: HTML has a low ratio of text to image area
0.0 T_KAM_HTML_FONT_INVALID BODY: Test for Invalidly Named or Formatted Colors in HTML
0.0 HTML_MESSAGE BODY: HTML included in message
1.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts
2.4 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50%
1.7 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/)
0.0 RCVD_IN_MSPIKE_BL Mailspike blacklisted
2.2 DRUGS_ERECTILE Refers to an erectile drug
1.4 FSL_HELO_BARE_IP_1 No description available.
1.3 RDNS_NONE Delivered to internal network by a host with no rDNS
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.
I think I lean toward following Return Path's guidance on the topic, which boils down to this: Promotions tab placement generally shouldn't hurt read rate, customers still find your messages, and will still buy from you. Placement in the Promotions tab might even mean your mail is less likely to be reported as spam by Gmail users. And Promotions tab placement, Return Path rightly points out, is inbox placement. It's better than the spam folder.
Agency COSO Media attempts to address some raised concerns. Appealing directly to senders who have "noticed a recent drop in your open rate on your email marketing campaigns," COSO Media suggests that "the best way to get emails back into the primary tab is to have your subscribers put you there."
Email Service provider MailChimp similarly suggests that you "encourage your subscribers to take these actions: Add your From email address to their Google Contacts[, and] Move your emails to the Primary tab."
Collaborative email builder Chamaileon provides this checklist of considerations:
Maybe you can't follow every step suggested here. Maybe not every suggestion makes sense for every sender (I certainly see lots of "complex" HTML email messages in the Primary tab). But hopefully these suggestions give you some idea of things to try when troubleshooting this issue (or deciding that it's fine to leave as is). Got something to add? Share it in comments below.
I think I lean toward following Return Path's guidance on the topic, which boils down to this: Promotions tab placement generally shouldn't hurt read rate, customers still find your messages, and will still buy from you. Placement in the Promotions tab might even mean your mail is less likely to be reported as spam by Gmail users. And Promotions tab placement, Return Path rightly points out, is inbox placement. It's better than the spam folder.
Agency COSO Media attempts to address some raised concerns. Appealing directly to senders who have "noticed a recent drop in your open rate on your email marketing campaigns," COSO Media suggests that "the best way to get emails back into the primary tab is to have your subscribers put you there."
Email Service provider MailChimp similarly suggests that you "encourage your subscribers to take these actions: Add your From email address to their Google Contacts[, and] Move your emails to the Primary tab."
Collaborative email builder Chamaileon provides this checklist of considerations:
- Don’t sell
- Authenticate your domain with DKIM and SPF records
- Greet recipients by name
- Have no more than one link in the email
- Don’t include pictures
- Don’t use RSS campaigns
- Keep the email short
- Don’t use heavy HTML
- Lots of images in your email
- More than one or two links in your email
- If it’s “from” your brand, rather than you
- Lots of fancy HTML code in your email
- Links to your social media profiles in your signature
Maybe you can't follow every step suggested here. Maybe not every suggestion makes sense for every sender (I certainly see lots of "complex" HTML email messages in the Primary tab). But hopefully these suggestions give you some idea of things to try when troubleshooting this issue (or deciding that it's fine to leave as is). Got something to add? Share it in comments below.
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)