The first statement is correct, the only thing you can trust initially, is the received: header. HOWEVER, depending on the circumstances, you can expand that trust, depending on who owns the server that is mentioned in the Received: header.
If we make a analogue example, of a building owner (on the deed) renting out a building to a hotel, that in turn, rents out rooms to customers. Lets say a customer on the hotel is sending out threats. Of course, intially, you can only trust the person who is on the deed, but since you learn from this, that its a hotel renting from the building owner, you can now trust the hotel staff to act against customers doing bad things, even tough the hotel does not own the building. In the same way, you can only initially trust the Received: header. But based on that information, you can then expand the trust, to cover also the X-AntiAbuse headers. One good internet example is Cloudflare. If you receive a HTTP request from someone, of course you cannot trust X-Forwarded-For, but only the HTTP_REMOTE_ADDR variable. But if you, based on the HTTP_REMOTE_ADDR, now learns the request comes from Cloudflare, you now know that you can trust the X-Forwarded-For header. So the information in whois is the network owner, usually a ISP. If a customer of the ISP is directly spamming you, of course, you turn to the ISP. But lets say you notice the IP in question belongs to McDonalds. Then you don't report to the ISP that is serving McDonalds, because you know, based on the IP owner, that the abuse comes from a wifi customer of McDonalds. Thus, you report the issue to McDonalds, that can disable the wifi account of that McDonalds customer. So you need to "expand" trust when you notice the intermediate company in question is trustworthy and not part of the spamming. So when you learn from the network that owns the IP (especially the PTR) that its a web hotel, you can now expand trust to the web hotel. You CAN'T assume every party responsible for abuse owns the IP space in question. If I start a web hotel, I would propably buy internet service from a ISP instead of managing own infrastructure and POP's. That would mean my name is not on the IP block, but my ISP. I would still expect any abuse report to come in through the web hotel and not to my upstream ISP. The information you find about a ASN or netblock is like the "deed" of a building. The "deed" is the person ultimately responsible for the building, but that is the LAST instance you turn to. Always turn to the instance closest to the spammer. -----Ursprungligt meddelande----- Från: Viktor Dukhovni via mailop <[email protected]> Skickat: den 4 december 2025 09:20 Till: [email protected] Kopia: Viktor Dukhovni <[email protected]> Ämne: Re: [mailop] AS29802 allows their customers to send phishing mails, disregards abuse complaints On Thu, Dec 04, 2025 at 07:55:35AM +0100, Sebastian Nielsen via mailop wrote: > Of course you can’t guess the abuse adress, but the server name is > clearly indicated in the X-AntiAbuse headers, then it shouldn’t be > that hard to find that the server name is actually the web hotel, > which is a customer to hivelocity.net, and thus just put abuse@ in > front of the server name. The ONLY header that can be trusted in a spam message is the "Received" trace header added by the local SMTP server. This contains the client IP address. Everything else is suspect. The party responsible for managing abuse from a given network is the service provider that manages the IP space, they can interface with their customers as/when appropriate. The WHOIS abuse contact for the ip block in question is the canonical contact for abuse reports. Period. -- Viktor. 🇺🇦 Слава Україні! _______________________________________________ mailop mailing list [email protected] https://list.mailop.org/listinfo/mailop _______________________________________________ mailop mailing list [email protected] https://list.mailop.org/listinfo/mailop
