Fun with new mailservers

I’m building a new set of mailservers for wordtothewise.com – our existing mailserver was “I’ll repurpose this test box for a week” about four years ago, so it’s long past time.
I tested our new smarthost by sending a test mail to gmail. This is the very first email this IP address has sent in at least three or four years, possibly forever:

host gmail-smtp-in.l.google.com[74.125.25.27] said:
421-4.7.0 [184.105.179.171      15] Our system has detected an unusual rate of
421-4.7.0 unsolicited mail originating from your IP address. To protect our
421-4.7.0 users from spam, mail sent from your IP address has been temporarily
421-4.7.0 rate limited. Please visit
421-4.7.0 http://www.google.com/mail/help/bulk_mail.html to review our Bulk
421 4.7.0 Email Senders Guidelines. u2si19966404pbz.202 – gsmtp (in reply to end of DATA command)

Sigh. IP warmup is hard.
I spun up our new MX and within three minutes, before I’d sent any test mail myself, I was seeing relay tests from the therichsheick spammer. Still scanning for open relays, still using the same Yahoo addresses. Followed immediately by someone else doing the same thing using gmail addresses.
 

Related Posts

DMARC and organizations

Comcast recently published a statement on DMARC over on their postmaster page. The short version is that Comcast is publishing a DMARC record, but has no current intentions to publish a p=reject policy for Comcast user email. Comcast will be publishing a p=reject for some of their domains that they use exclusively to communicate with customers, like billing notices and security notices.
Comcast does point out that Yahoo! and AOL’s usage of p=reject is “not common usage.”
This is something a lot of people have been arguing loudly about on various mail operations lists and network lists. DMARC is about organizational identity. In fact, I was contacted about my DMARC primer and told that I didn’t mention that it’s not about domains, it’s about organizations.
The way I read the DMARC spec, it is all about organizational identity. The underlying theme being that the domain name is linked to a particular organization and everyone using email at that domain has some official relationship with that organization. I’ve always read the spec mentally replacing organization with corporate brand. This was for brands and organizations that strictly control how their domains are used, who can use those domains and how the mail is sent with those domains.
I never expected any mailbox provider or commercial ISP to publish a p=reject message as it would just break way too much of the way customers use email. And it did break a lot of legitimate and end user uses of email. Many organizations have had to scramble to update mailing list software to avoid bouncing users off the lists. Some of these upgrades have broken mailbox filters, forcing endusers to change how they manage their mailboxes.
Even organizations see challenges with a p=reject message and can have legitimate mail blocked. At M3AAWG 30 in San Francisco I was talking with some folks who have been actively deploying DMARC for organizations. From my point of view anyone who wants to publish a DMARC p=reject should spend at least 6 months monitoring DMARC failures to identify legitimate sources of email. The person I was talking to said he recommends a minimum of 12 months.
This is just an example of how difficult it is to capture all the legitimate sources of emails from a domain and effectively authenticate that mail. For a mailbox provider, I think it’s nearly impossible to capture all the legitimate uses of email and authenticate them.
It remains to be seen if the other mailbox providers imitate Yahoo! and AOL or if they push back against the use of DMARC reject policies at mailbox providers. Whatever the outcome, this is a significant shift in how email is used. And we’re all going to have to deal with the fallout of that.

Read More

Dealing with DMARC for Mail intermediaries

I’ve been getting some mail and calls from folks looking for help on resolving the issue of DMARC bouncing. Some of these calls are from ESPs, but others are from SAAS providers who have users that have signed up with yahoo.com addresses and are now dealing with mail from those users bouncing, even when mail is going back too those users.
None of the solutions are really great, but here are a couple options.
1) Prohibit users users from sending with @yahoo.com header-from addresses. This will be challenging for some companies for all sorts of reasons. I have seen a number of people suggest switching to @hotmail.com or @gmail.com addresses. This only works as long as Gmail and Hotmail/Outlook don’t start publishing p=reject policies. It’s unclear if they’re even considering this at all, but it may happen.
2) Rewrite the header-from address from @yahoo.com to something you control. One thing I’ve been suggesting to customers is set up a specific domain for rewriting, like @yahoo.ESP.com. This domain would need to forward mail back to the @yahoo.com users, which does add another layer of complexity as these addresses will become spam magnets. Thus the forwarding IP should be on a distinct and separate IP, to prevent interference with other systems. Note, too, that any users sending to these reply addresses from a domain protected by DMARC p=reject will bounce.
If you have questions or want to ask specifically about what to do in your setup, I’ve blocked out some time in my schedule next week for companies. If you want more information about this please contact me to for available times, information requirements and pricing.

Read More

June 2014: The month in email

Each month, we like to focus on a core email feature or function and present an overview for people looking to learn more. This month, we addressed authentication with SPF.
We also talked about feedback mechanisms, and the importance for senders to participate in FBL processes.
In our ongoing discussions about spam filters, we took a look at the state of our own inboxes and lamented the challenge spam we get from Spamarrest. We also pointed out a post from Cloudmark where they reiterate much of what we’ve been saying about filters: there’s no secret sauce, just a continuing series of efforts to make sure recipients get only the mail they want and expect to receive. We also looked at a grey area in the realm of wanted and expected mail: role accounts (such as “marketing@companyname.com”) and how ESPs handle them.
As always, getting into the Gmail inbox is a big priority for our clients and other senders. We talked a bit about this here, and a bit more about the ever-changing world of filters here.
On the subject of list management, we wrote about the state of affiliate mailers and the heightened delivery challenges they face getting in the inbox. We got our usual quota of spam, and a call from a marketer who had purchased our names on a list. You can imagine how effective that was for them.
And in a not-at-all-surprising development, spammers have started to employ DMARC workarounds. We highlighted some of the Yahoo-specific issues in a post that raises more questions.
We also saw some things we quite liked in June. In the Best Practices Hall of Fame, we gave props to this privacy policy change notification and to our bank’s ATM receipts.
We also reviewed some interesting new and updated technology in the commercial MTA space, and were happy to share those findings.

Read More