On a mailing list I subscribe to, someone recently asked for assistance with getting mail delivered to Microsoft's Live.com and Hotmail.com domains. Apparently the poster works for an internet provider that had a compromised account or two, and Microsoft was blocking their mail as a result.
A kind soul posted this reminder in response:
"The most efficient and effective way to address any deliverability problem is by submitting the issue to our dedicated deliverability support team. Senders can do this by filling out a form with detailed information necessary to diagnose the problem. The form can be found here: https://support.microsoft.com/en-us/getsupport?oaspworkflow=start_1.0.0.0&wfname=capsub&productkey=edfsmsbl3&ccsid=. Going directly to deliverability support will ensure that we have the right information to investigate the cause and recommend the right solutions quickly."
Those of us who have been around a while already have that URL bookmarked, but I thought I would share it here for new folks who might not already know it.
(June 2015 update: Link has been updated to most current version.)
Check out this neat thing: Email Privacy Tester
Smart web developer and systems admin Mike Cardwell put together something neat that I think you'll want to check out: Email Privacy Tester. Plug in your email address, and his system will send you an email message. That message will contain a whole bunch of different types of active content in various different wrappers and encodings, to see which of them are triggered by your MUA (mail user agent; aka email client). I did a quick test to a Gmail account and I already see one thing that I don't like, something Gmail executes automatically without asking me.
Topics:
email privacy tester,
mike cardwell,
neat
DMARC does only one thing (but pretty well)
DMARC (specifically, DMARC with a p=reject policy) does one thing: It makes it very difficult for somebody to use your domain in a from address without your permission. It doesn't stop spam from open relays, open proxies, snowshoeing network blocks, nor does it prevent people from ignoring CAN-SPAM and continuing to mail you after you have unsubscribed.
It doesn't do all those other things; but the one thing it does, it seems to do it very well.
It has limitations; yes. It doesn't specifically do anything the cousin domain problem (deceptively-registered domains with similar, but not exactly the same names). It makes mailing list management more complex. And it makes it so for the most part, users of email service providers (ESPs) cannot use Yahoo or AOL addresses as from addresses (because Yahoo and AOL publish strict DMARC policies).
Is anybody saying that DMARC is a magic bullet? I don't think so, but a better question is -- Does DMARC help? Yes, says Yahoo.
But spammers eventually moved on to forging one of Yahoo's domains, so it was a pointless exercise, others have said. Pointless exercise? I don't agree with that at all. It's true that Yahoo only published a strict policy for one of their domains; it's almost like they decided to lock only one door first, either because it was the most abused, or perhaps because you have to start somewhere (and maybe want to see how that goes before adding others).
But if I were a Yahoo or AOL, or a financial institution, or well known retail brand, would I think it is a win; a gain, quite likely a long term one, if I could keep bad guys away from using my domain in the from address of their bad mail? Yes, I would. DMARC helps. And I think when you look at who is implementing DMARC, I suspect that I'm not the only one who feels that way.
This reminds me so much of the days when I first got involved in spam fighting. Open relaying mail servers were a big bad problem. Spammers exploited them regularly and with great vigor. I was so tired of dealing with spam from open relaying mail servers that I started to block it, an effort that ended up becoming the MAPS Relay Spam Stopper, a coordinated third party blacklist that easily allowed mail system administrators to block mail from open relaying mail servers.
Spammers cried about being blocked. But not just spammers; there were also a non-zero number of people who claimed that I was part of some big conspiracy to wreck email. People called my employer, trying to get me fired. A number of people threatened to sue. A few high-profile savvy internet users like John Gilmore, explained that they needed to be able to legitimately relay mail for other people, and that blocking mail from those servers was akin to censorship.
Somehow, we survived all of that. Eventually, people seemed to accept this change. We got to a point where, while you do still see open relays out there from to time, there's a general consensus that it's a bad way to configure a mail server. But for us to get there, a number of us had to first band together and take action; personally implementing policies wherein we block mail from misconfigured servers used to shovel abusive, unwanted mail, while people who didn't understand why it mattered gave us hell for at the time.
I find a lot of parallel there; my point, other than I'm old and 1998 was a long time ago, is that I have a feeling that this will be a non-issue in a few years, and even if sites don't broadly implement DMARC with a p=reject policy, enough of them will do so that you're truly going to have to just deal with it.
It doesn't do all those other things; but the one thing it does, it seems to do it very well.
It has limitations; yes. It doesn't specifically do anything the cousin domain problem (deceptively-registered domains with similar, but not exactly the same names). It makes mailing list management more complex. And it makes it so for the most part, users of email service providers (ESPs) cannot use Yahoo or AOL addresses as from addresses (because Yahoo and AOL publish strict DMARC policies).
Is anybody saying that DMARC is a magic bullet? I don't think so, but a better question is -- Does DMARC help? Yes, says Yahoo.
But spammers eventually moved on to forging one of Yahoo's domains, so it was a pointless exercise, others have said. Pointless exercise? I don't agree with that at all. It's true that Yahoo only published a strict policy for one of their domains; it's almost like they decided to lock only one door first, either because it was the most abused, or perhaps because you have to start somewhere (and maybe want to see how that goes before adding others).
But if I were a Yahoo or AOL, or a financial institution, or well known retail brand, would I think it is a win; a gain, quite likely a long term one, if I could keep bad guys away from using my domain in the from address of their bad mail? Yes, I would. DMARC helps. And I think when you look at who is implementing DMARC, I suspect that I'm not the only one who feels that way.
This reminds me so much of the days when I first got involved in spam fighting. Open relaying mail servers were a big bad problem. Spammers exploited them regularly and with great vigor. I was so tired of dealing with spam from open relaying mail servers that I started to block it, an effort that ended up becoming the MAPS Relay Spam Stopper, a coordinated third party blacklist that easily allowed mail system administrators to block mail from open relaying mail servers.
Spammers cried about being blocked. But not just spammers; there were also a non-zero number of people who claimed that I was part of some big conspiracy to wreck email. People called my employer, trying to get me fired. A number of people threatened to sue. A few high-profile savvy internet users like John Gilmore, explained that they needed to be able to legitimately relay mail for other people, and that blocking mail from those servers was akin to censorship.
Somehow, we survived all of that. Eventually, people seemed to accept this change. We got to a point where, while you do still see open relays out there from to time, there's a general consensus that it's a bad way to configure a mail server. But for us to get there, a number of us had to first band together and take action; personally implementing policies wherein we block mail from misconfigured servers used to shovel abusive, unwanted mail, while people who didn't understand why it mattered gave us hell for at the time.
I find a lot of parallel there; my point, other than I'm old and 1998 was a long time ago, is that I have a feeling that this will be a non-issue in a few years, and even if sites don't broadly implement DMARC with a p=reject policy, enough of them will do so that you're truly going to have to just deal with it.
OpenDKIM & SpamAssassin Gotchas on Ubuntu 12.04
Allow me to share with you my rough notes compiled during my recent configuration of email and DKIM on a new Ubuntu VPS installation. Hopefully these helpful hints will help the next poor soul trying to get DKIM up and running on the first try:
(Originally posted to my personal blog, but I think it makes more sense here since it's talking about email, spam filtering and authentication.)
- SpamAssassin seems to want to fail DKIM keys from Gmail or Google Apps with an error of T_DKIM_INVALID. There's some noise online about this perhaps being an issue with clock synchronization, but it is more likely that you don't have one or more perl modules installed necessary for SpamAssassin to properly decode the DKIM key. The fix turned out to be simple; installing these packages solved that issue:
sudo apt-get install libmail-dkim-perl
sudo apt-get install libcrypt-openssl-random-perl
sudo apt-get install libcrypt-openssl-rsa-perl
(Thank you, Henrik Schack, for the tip!) - If you are new to OpenDKIM's Authentication Results header, you're going to be confused by this. You'll see a lot of DKIM as having passed, but with a reason of "1024-bit key; insecure key." This made me start poking around, looking at file permissions for my various keys (I set up signing for multiple domains). I assumed I had done something wrong, but I couldn't find any issue no matter where I looked. It turns out that it is not really an issue at all. What the error message actually means is that the domain that send you the message isn't using DNSSEC. Long term? Sure, yeah, everybody should look at DNSSEC, but one thing at a time.
- Here's what nobody tells you if you're DKIM signing multiple domains on the same server, using OpenDKIM: It is possible to interpret the opendkim.conf configuration file in a way that would lead you to add multiple sections starting with "domain," setting a selector for each and linking to different keys. Truth be told, OpenDKIM will only honor the LAST one of these sections, signing mail for only one of your domains. It won't generate any sort of error message, either, so it can be frustrating to understand what is happening. Remember, if you want to set up signing for multiple domains, look at how to configure the SigningTable and KeyTable settings in OpenDKIM.
(Originally posted to my personal blog, but I think it makes more sense here since it's talking about email, spam filtering and authentication.)
Topics:
dkim,
howto,
opendkim,
spamassassin,
ubuntu
106 miles to Chicago
If you've ever set up catch-all domain names, that accept mail destined to any address, or set up your MTA in a way where all mail is accepted before checking to see if the recipient is valid, then you've probably seen emails containing this quote: "It’s 106 miles to Chicago, we got a full tank of gas, half a pack of cigarettes, it’s dark… and we’re wearing sunglasses."
The movie isn't new to me, but this is the first time I've run across the quote in this context. Apparently, for a while now, some spammer has been trying to find open relaying mail servers and seems to use this quote in almost every open relay attempt. I guess they just got around to trying it some place where I would notice the attempts.
Blast from the past: Challenge/Response Filtering?
A few weeks ago, somebody on the Mailop list asked about an email they received. Turns out, it was a Challenge/Response spam filter. You know, one of those emails from a robot that says "click here to prove you're not a robot, otherwise I'm not going to deliver your email on to the intended recipient." That doesn't work very well -- do you think Amazon has people waiting to click on that link each time they send out an emailed order receipt? Yeah, yeah, supposedly you (the user with the C/R spam filter) can whitelist that stuff, but you're going to miss something.
Challenge/Response filtering seems to have mostly disappeared; this was the first time I had heard about it in many years. But it's not the first time I've blogged about it; look all the way back to this MediaPost article from 2006, and you can see me raise still-extant concerns relating to how C/R works.
Click here to jump in the time machine and read what else I've written about C/R in the past.
Challenge/Response filtering seems to have mostly disappeared; this was the first time I had heard about it in many years. But it's not the first time I've blogged about it; look all the way back to this MediaPost article from 2006, and you can see me raise still-extant concerns relating to how C/R works.
Click here to jump in the time machine and read what else I've written about C/R in the past.
Subscribe to:
Posts (Atom)