Spamcop mail changes

Spamcop is shutting down it’s email service. While anyone could report spam using Spamcop, the system also provided users email addresses behind the Spamcop filters. This shut down should have no major impact on senders. Email addresses in use will still be accepting email, but that mail will simply be forwarded to another address, instead of users being able to access it through POP or IMAP.
The one problem some senders may have is IF they are solely authenticating through SPF and they are publishing a p=reject DMARC statement. This may result in some of the mail being rejected at the forwarding mail server, like AOL, Yahoo and other services respecting DMARC policy statements.
User forwarded mail will be coming from 68.232.142.20 (esa1.spamcop.iphmx.com) and 68.232.142.151 (esa2.spamcop.iphmx.com). If you don’t want to apply DMARC policy to known forwarded mail, those are the IPs to special case.

Related Posts

DMARC and report size limits

I just saw an interesting observation on the dmarc-discuss mailing list. Apparently some of the larger providers who are implementing DMARC for inbound email may not be handling some of the grubbier corners of the spec perfectly. That’s not surprising at all – early adopters tend to deploy code that implements early versions of the draft specification – but I can see this particular issue tripping up people who are beginning to deploy DMARC for their outbound mail.
DMARC includes the feature of requesting feedback reports about authentication failures – you just include the email address you want them sent to as a mailto: URI in the rua= and ruf= fields:

Read More

Spammers react to Y! DMARC policy

It’s probably only a surprise to people who think DMARC is the silver bullet to fixing email problems, but the spammers who were so abusing yahoo.com have moved on… to ymail.com.
In the rush to deploy their DMARC policy, apparently Yahoo forgot they have hundreds of other domains. Domains that are currently not publishing a DMARC policy. Spammers are now using those domains as the 5322.from address in their emails. The mail isn’t coming through any yahoo.com domain, but came through an IP belonging to Sprint PCS.
ymail_dmarc
This is just one example of how spammers have reacted to the brave new world of p=reject policies by mailbox providers. If only the rest of us could react as quickly and as transparently to the problems imposed by these policy declarations. But changing software to cope with the changes in a way that keeps email useful for end users is a challenge. What is the right way to change mailing lists to compensate for these policy declarations? How can we keep bulk email useful for small groups that aren’t necessarily associated with a “brand”?
The conversation surrounding how we minimize the damage to the ecosystem that p=reject policy imposed hasn’t really happened. I think it is a shame and a failure that people can’t even discuss the implications of this policy. Even now that people have done the firefighting to deal with the immediate problems there still doesn’t seem to be the desire to discuss the longer effect of these changes. Just saying “these are challenges” in certain spaces gets the response “just deal with it.” Well, yes, we are trying to deal with it.
I contend that in order to “just deal with it”, we have to define “IT.” We can’t solve a problem if we can’t define the problem we’re trying to solve. Sadly, it seems legitimate mailers are stuck coping with the fallout, while spammers have moved on and are totally unaffected.
How is this really a win?

Read More

ReturnPath on DMARC+Yahoo

Over at ReturnPath Christine has an excellent non-technical summary of the DMARC+Yahoo situation, along with some solid recommendations for what actions you might take to avoid the operational problems it can cause.

Read More