Starting on December 19th we’re no longer going to accept mail submitted to our SMTP AUTH system with a URI classified as black, grey, red, or gold on URIBL. These categories contain domains that are either actively used by spammers or found in unsolicited bulk mail. This is currently being treated as a trial change.
The “grey” category is a special case. It contains domains that are used by bulk or commercial mail, which may not be spammers in the strict sense, but are nevertheless against our policy for SMTP AUTH submissions (no bulk or marketing mail).
Our goal is quality of mail through our submission system in order to maintain a high reputation for our customers that depend on us for routine communication. Because we are not a “bulk mail” outfit we are unfortunately unable to accommodate bulk mail use cases, and it would be more appropriate to use the mailer’s service to send bulk mail instead of ours.
If you find you’re having trouble submitting messages after this change, contact support so we can investigate. Marketing-type mail should be sent directly to the intended recipient and not rely on forwarding or resending.
5 replies on “Mail: New URIBL Restrictions on SMTP AUTH”
a. you should allow submissions to abuse@ so that users may seek help from an admin. and it shouldn’t be limited to the same domain.
b. your argument for including “grey” category doesn’t make sense. how is it against your policy to try to send a SINGLE email containing a link to constantcontact.com?
The abuse@ recipient (any domain) already get special consideration with the content filters as do reports to SpamCop. This change will not affect that.
We’ve simply had too many people abusing our AUTH with marketing ESP content (tracking links, unsub links, automated forwarding of ESP mail) that ends up lowering the reputation of our IP addresses, which causes complaints about mail being rejected or delivered into “spam”. It’s never been allowed and this enforces an existing policy with automation. Previously if we caught someone we’d revoke their AUTH privileges manually. The issue, we suspect, is people using our service because it’s cheaper than using an ESP that charges on volume.
If there’s something that deserves special consideration we can review it on an individual basis.
For the “single” case are you referring to someone wanting to forward a marketing mail through our system?
yes, are we not allowed to forward a marketing email?
Generally speaking because marketing mail will have URIs that could match URIBL_GREY, the answer will be no. The problem is that we don’t have a different solution for people receiving forwarded marketing email who then report our SMTP AUTH service as sending spam since our server was the source. Ideally marketing lists should be direct subscription, not relying on forwarding.