Spamhaus unsubscribe requirement

Spamhaus have added me to their CSS list and I'm trying to find out why. It might be a technical issue or it could possibly be something else. (I think it is defamatory to tell the world someone has a bad reputation without giving them evidence of a reason, but I'll leave that for now.)

Their current requirement is that I must add unsubscribe headers to my mail, but that worries me. The bulk of my mail is personal to friends or other ordinary contacts. The rest is related to my involvement in Church or similar institutions. I do not send bulk mail and I have no subscribers, so how can I provide an unsubscription mechanism? At best, it would have to be a dummy mechanism that did nothing, but how would that work as spammers could do the same. I cannot provide a genuine mechanism because there is nothing to unsubscribe.

Also, I worry that friends might get the impression I have subscribed them to some company's bulk lists without their knowledge or permission and I could lose their friendship very quickly if I complied.

The Internet, once we have paid for our access, needs to be available to all to use ethically and lawfully. We can't let it become the property of big companies to use to milk us all or spy on us all.

In the meantime I have a test e-mail bouncing around between my incoming and outgoing servers. The incoming server won't accept my outgoing server's bounce messages because they're both on Spamhaus's list!
 
The Troubleshoot section in the checker outlines the issues with the current configuration. Please follow the recommendations in the checker and ensure you pass all three checks before opening a ticket.https://check.spamhaus.org/results?query=84.92.47.176Regards,
(Emphasis mine.) I have corrected the HELO issue but that's not good enough until I set the unsubscribe link and header and enable IPv6 which my router and so far as I know my ISP does not provide. These are the other two recommendations.

I have replied explaining why this would be "technically possible but socially difficult" but have no great expectations they will move.

Pity, Spamhaus was a very useful tool until they did this.
 
This is generic advice about running a mail server. CSS is a snowshoe spam list; snowshoe spam is sent from addresses that have not previously sent spam, either fresh address block allocations, or compromised servers. The first thing to do is check your mail logs, to see if you are spamming; you might have an infected client behind the server, another risk factor is a vulnerable web server that can access the MTA. Note that snowshoe spam is often low volume. The other possibility is that you are in a block of addresses that has been inferred to be spammer controlled. Either way the listing should age out in a few day if the underlying problem goes away.

If you aren't the spammer, the onus is on the service provider to deal with it.
 
Unfortunately no, the quote was from the specific reply to my ticket, so not generic advice but a requirement for delisting in my specific case.
 
Unfortunately no, the quote was from the specific reply to my ticket, so not generic advice but a requirement for delisting in my specific case.
It still sounds generic to me; how could they know whether you have added unsubscribe headers to the bulk mail you don't send. The only possible way is if your email is going into their spam traps, and that would rule-out delisting anyway.
 
They are taking the information from their test procedure to which I have sent test messages, so they know exactly what my mail does and doesn't provide. The first test result had three failures:

1. Does not comply with Google/Yahoo requirements (unsubscribe requirements for bulk e-mail). I do comply with the requirements for personal mail as published by Yahoo, but that's evidently not good enough for Spamhaus. They want me to comply with bulk requirements even though I'm not a bulk sender. I'm not sure how anyone can tell whether any individual mail is part of a bulk list or not, anyway. Most bulk senders send each one individually to reduce the risk of data breaches. However, if they distinguish in their requirements they must have a way (and I think we can all guess what that is - after all, if they're spending a lot of money providing a free messaging service they must be getting something worthwhile out of it). Spamhaus cannot tell, of course. They have probably put me on the list because my year's delisting has expired, but I have to pass their test before I can come off.

2. Not IPv6 ready. My ISP doesn't provide IPv6 yet so this isn't really a reflection on me and shouldn't be used as a basis for assessing my trustworthiness, but it apparently is. This is not under my control.

3. HELO did not comply with rDNS. This seems to be a new requirement as it never has and I was successfully delisted last year. I have now changed this to match though Spamhaus seem confused by that and have asked me which one is correct.

I gather List-unsubscribe headers can have a text part as well as a link so I suppose I'll just have to make that an explanation they're not actually on a list to start with and set up a page which claims (falsely) they have been unsubscribed, since it's impossible to unsubscribe someone from a list which doesn't exist - but how does that help with spam? Spammers could just add a bogus List-unsubscribe process which does nothing too.
 
I've been down that road. With email configured for all the current "gotta haves", Spamhaus still blacklist my site. In the North Carolina county I'm in, 3/4 of the count ISPs do not support IPv6. The server is headless, so the Spamhaus "how to get unblocked" process of sending an email to the server with a URL that replies to SpamHaus could not easily be done (it's at a local firehouse since they use it for mapping data and notifications). As such, I could not bring up a web page from the URL they supplied.
The only recourse I had was to have the service provider contact Spamhaus and verify that even though the IPv4 address was in their block of IP addresses that I was a vetted provider. It took a few weeks to get that to happen. Once that was done, I was good.
My take on the situation is twofold. SpamHaus has a default "If you're in a IP address block with a fixed IP you must be a spammer" view of the world, a sort of "you are guilty until proven innocent" and large ISP providers of service with a fixed IP address that have near zero support after the sale, and do not wish to complicate the sales parcel by dealing with this proactively when setting up new fixed IP service.
With the advent of CGNAT, existing ISP infrastructure can justify not upgrading their system to IPv6 which is bad for everyone in the long run. As such, the "One IPv4 address associated with hundreds of users" challenges identifying spammers by IP address. In the world of security, everything is a moving target.
So make sure you have all the latest and greatest pieces of security in your email setup done correctly, and work with you ISP to pass the good word on the Sp;amhaus. I see no impetus for these large organizations (Spamhaus, ISPs, cloud hosting) to change.
 
They are taking the information from their test procedure to which I have sent test messages, so they know exactly what my mail does and doesn't provide.
Clearly this procedure is not really aimed at you. The people that pay for Spamhaus, and most that use it for free, regard mail servers like yours as a risk. Without lists like CSS a lot more spam would get through to resource intensive content filtering.

They have probably put me on the list because my year's delisting has expired, but I have to pass their test before I can come off.

The protection may have expired, but it's unlikely that you were listed just because of that.
 
My take on the situation is twofold. SpamHaus has a default "If you're in a IP address block with a fixed IP you must be a spammer" view of the world, a sort of "you are guilty until proven innocent"

What's your evidence for that?

With the advent of CGNAT, existing ISP infrastructure can justify not upgrading their system to IPv6 which is bad for everyone in the long run. As such, the "One IPv4 address associated with hundreds of users" challenges identifying spammers by IP address. In the world of security, everything is a moving target.
It doesn't matter, a listing implies one of two thing: either there is a spam source at that address or a dynamic address is attempting to deliver directly to MX - both are equally damning.
 
If you are sending mail from a dynamically assigned prefix you will always get listed on various spam lists. First and foremost because you can't create a valid reverse record (which in itself will cause a lot of mail to be rejected as it is a hard requirement for sending mail to have a valid RR) and secondly because any responsible ISP lists those prefixes as dynamically assigned and not intended for mail delivery - because 99.9% of all mail originating from dynamic prefixes are simply windows pestholes taking part in some spam botnet...
Any mail originating from those prefixes therefore will automatically trigger listing in various blacklists and have to be whitelisted on request. Check at https://multirbl.valli.org/ if you are listed anywhere else - if you are in fact sending from a dynamically assigned prefix, several other RBLs will also have you listed (purely on the basis of the IP of your mailserver).

Unsubscribe headers only belong in messages from mailing lists or bulk mail services, those are definitely not triggers for blacklisting on the basis of single messages.

Spamhaus (just as other reputable RBLs) usually sends an automated message to one of the mandatory accounts for your domain (i.e. postmaster@ and/or abuse@) with a copy of the message (or at least metadata from it) that triggered the listing and what criteria caused it. So you should have received a report with the details of the listing (you DO have your postmaster@ and abuse@ set up as required by RFC5321/2142?)
 
you are on an ip block your isp declared as residential / dynamic block even if you have a static ip address
i had this problem in the past with microsoft and others.
if you can't get thru the delisting bs you can
- ask your isp for a way to relay thru them (this worked ok in the past at least around here but recently they wont allow you to use them as a relay)
- rent the cheapest vps where you can control the reverse ip mapping for both ipv4 and ipv6. send all the email thru that ip
this vps method may not work but i had various vps-s from digital ocean, netcup, hetzner and they could send mail without problems.
- sign a contract with some smtp provider like sendgrid or others
 
you are on an ip block your isp declared as residential / dynamic block even if you have a static ip address
i had this problem in the past with microsoft and others.
if you can't get thru the delisting bs you can
- ask your isp for a way to relay thru them (this worked ok in the past at least around here but recently they wont allow you to use them as a relay)
- rent the cheapest vps where you can control the reverse ip mapping for both ipv4 and ipv6. send all the email thru that ip
this vps method may not work but i had various vps-s from digital ocean, netcup, hetzner and they could send mail without problems.
- sign a contract with some smtp provider like sendgrid or others
- just get a free account at some relay service like e.g. smtp2go and use them as a relay host. I'm doing that for anything microsoft-related because their broken email-island constantly randomly rejects inbound mail even by 100% reputable mailservers and -domains, (but they happily send 100% of spam originating from their spamcloud without any filtering) and I have better things to do than dealing with elitist idiots that don't respect any RFC requirements... (e.g. they do not have a postmaster@ or abuse@, you have to go through some BS web portal only accessible with a microsuck account which I definitely won't create just for their BS)

In general no* mailserver should be running a) in a dynamic/residential IP block and b) on some residential internet connection which might pose various restrictions (CG-NAT, filtering/censoring, blocked inbound ports etc pp). Both are prime recipes to ruin the reputation of a maildomain.


*with the exepction of maybe some fallback secondary MX or intermediary host, not usually/directly involved in delivering or receiving mail from/to external domains. IIRC there are even some exceptions for secondary MXs on otherwise hard requirements. That's why spammers often try to deliver their junk to a secondary MX first.
 
the problem is the ISP will happily sell you a 'fixed ip' contract then fsck you in various ways like declaring a residential block or whatever. mine deleted my reverse mapping and then told me a lot of bs like they did nothing and that is my fault because my mx is called ns.domain.tld instead of mail.domain.tld and other crap like this. in the end i complained at ripe and then after about 2 days they fixed their mistake. luckily i had another host thru which i could send mail in that period
 
At a reputable ISP you should always be able to either set the PTR record directly via some backend or (espectially if you leased several IPs) get a reverse delegation for your prefix so you can define/run your own NS handling the PTR records. (BTW: some of those 'new, hip' authorative-only nameservers have very nasty bugs/'special behavior' when it comes to reverse zone delegations or ipv6 reverse records, which can also ruin your day. Trusty old bind9 still works best in this regard, but many ISPs sadly use those weird ones...)

That being said, most (large/huge) ISPs are an absolute dumpster fire of crusty, ancient business models and bureaucracy and can't even handle such requests. Just don't do any business with them any more, so they finally die out like the dinosaurs they are...
 
I'm with bob. I think their service is taking you for a ride.

Out of curiosity, how would I test my own mail server against them?

I'm not sure what you mean by taking me for a ride. They control the list which governs e-mail reputation, so it's not a joke being on it if you want your mail to reach your contacts. I use it myself to defeat spam and it works very well. If I can't get off their list I can't rely on my mail to arrive. I am still negotiating with them about their reluctance to delist me until I satisfy two impossible conditions.

As for checking your own mail, you can check whether you're listed at https://www.spamhaus.org/. I then followed links to a check URL but I'm not sure whether you have to be listed to use that. Basically you send them an e-mail and their system tells you what's wrong with it. Mine failed the three checks I listed, though only one of those is really relevant to reputation and I have corrected that.

However, while I was negotiating with them the listing expired on CSS. Their helpdesk person wrote something must have changed - yes, I had aligned my HELO with my rDNS - and since I was no longer on CSS I could remove myself from the SBL. I'm not sure how technical their helpdesk staff are; often these people are trained to follow scripts, of course, so when you start asking real questions about how things work they might not know the answer. Was that what you meant by taking me for a ride? I can see that for a helpdesk script-follower "ensure you meet all our requirements before asking for help" could be a standard answer.

Anyway, I thanked the person for the help, even though the situation had resolved itself automatically before we really reached any agreement and just hope there's not really a problem with any of my systems.

I am slightly concerned that my HELO is now using a subdomain of my ISP's, because it is effectively identifying itself as part of their system when although it is, in the sense it is operating on their subnet, it is not actually under their control. That feels rather uncomfortably like "passing off". I'm wondering whether to do nothing until they complain or ask them if they can change it to one of my domains and hope they don't just withdraw it completely.
 
I am slightly concerned that my HELO is now using a subdomain of my ISP's,
So you DO run that server on a residential line without a proper reverse record?

If that's the case, RBLs are the least of your concern - pretty much every mailprovider (and every sensible mailserver admin) makes it a hard requirement that the servers published hostname/fqdn MUST have a PTR record matching the IP of the sending host. This is one of the earliest checks any mailserver performs and if it fails, it simply refuses any further operation by that host, let alone accept any data.
This usually is also true for any FQDN/PTR record containing 'in-addr.arpa', which also indicates a dynamically assigned address and generated PTR record.

Do yourself a favor and use a mail relay service. You may still use your server to receive mail (altough this may still fail in various cases), but sending email *reliably* simply has to follow some basic standards and requirements, which explicitly exclude using dynamic/residential prefixes. There is nothing to 'fix' here and manually de-listing from any RBL won't change that.
 
the reverse mapping requirement is a bit of bs and "undemorcatic" as it is hard to manage it yourself without isp's help and talking your isp in doing it is usually hard.
it's usually straight forward on a vm but close to impossible with an isp. also the 'residential blocks' bollocks is another instrument the hyperscalers use against you.
they should just use spf and dkim and call it a day.
 
Back
Top