gnarlymarley

I had seen other sites, which tells me a possible intermittent internet issue. Though I seem to not have gotten hardly any spam during that time so I was not able to test it.

If the Received: lines can be trusted, then you can look at the "from" of the Received: line and trace it back. I think the issue of unpicking it is technically difficult as you can only trust the Received: lines that are placed by your ISP or your mail server. You would only be able to trace it back to the specific server that sent it to your mail server.

Sometimes it is good to see a new post so that somebody sees it. I had forgotten about it too.

I keep hoping that someone at SpamCop might pick up the following request and to implement this. From what I currently understand, SpamCop only follows certain whois referral entries. Be nice if they could follow all of them. This was noticed around 2012 when Apnic and RipeNCC ran out of IPv4 addresses and started exchanging then with the other RIRs. Richard was having to manually update all the entries to sort them out. Manual changes take too long and it would be better to automate it.

Not likely that google will be giving back their IPs with cloud computing. More likely they spammers will give up the cloud instance to someone else, who may or may not be a spammer. Hence if you sign up with any cloud service, you could be getting an IP that was previous use to spam.

In the past, SpamCop has been more about reporting the email than it has the links inside. I think this and the number of outgoing reports is why they put the limit down to eight or ten. If all the high-level URLs are the same, it would be nice if they could count it as a single report and allow all of them to be reported.

Any reported IPs help feed the SCBL, however, there are thresholds in the number for them to get onto the list. If there are more reports, IPs seem to be listed longer. I think it requlres reports from more than one person (probably at least four or five people) to be listed on the SCBL. Any IP on the SCBL will automatically be delisted about 24 hours after the last reported spam. I have seen it automatically delist after about 4 hours, so I suspect that different amounts of spam reports can change how long it will be listed. I believe SpamCop did this because spammers were returning their burnt IP blocks back to the registrar and good people were acquiring IPs from these burnt blocks. I suspect this is internal politics and the google admins could be tired of being forced to allow any business potential "test" sign-up.

I have not detected any issues lately. Perhaps this was resolved?

One quick note when your mailhost was changed, you can go back to all your old tracking URLs that previously didn't report and report any that are less than two days old.

Enabling mailhosts on your SpamCop account should prevent SpamCop from looking past your ISP's server with the correct date, as long as you do not have a outlook.com also on your mailhosts. It is possible that an admin found a hung queue and released it.

SpamCop uses the date in the Received header, which is placed by my email server. I enabled mailhosts so SpamCop would use the correct date. Spammers have been adding other headers with bogus dates for a while.

You may be able to try a different browser. Per the following post, it appears to be a coding issue.

SpamCop uses RFC URL standards. The links should work the same in SpamCop as they do in your browser. Years ago, spammers started using invalid characters to attempt to avoid SpamCop. People would see the characters and then naturally would manually change them to go to the links.

yeah, looks like a direct translation from the stuff I have seen in the past. I don't think they are winning, but then I was able to block those ISPs because I run my own email server and should never get email from them. As petzl suggests, you will need to contact your ISP directly if it is coming from them. You might need to ask your ISP for possible solutions.

Not this one is it? Every so often they do a major upgrade on the forums and the links can break.

Not sure if this is related, but I got a bounce earlier from smtp16 where it is struggling at sending to the deputies. And yes, my bounce showed a gmail address for the deputies. Diagnostic-Code: smtp; 5.4.7 - Delivery expired (message too old) 'DNS Soft Error looking up gmail.com (MX) while asking recursive_nameserver0.parent. Error was: unable to reach nameserver on any valid IP' (delivery attempts: 0)

Once you get mailhosts setup, you can revisit any of the tracking URLs and see what it does.

I tried copying the missing headers in to my account and it doesn't seem to strip them out. https://www.spamcop.net/sc?id=z6731316407zb111e9d2cfa7f8b5c5d6236c6058460cz Hopefully the deputies can see this and figure out there the problem might exists.

The IP 173.231.200.200 is listed in the block list. Looking at https://www.spamcop.net/w3m?action=checkblock&ip=173.231.200.200, it appears that there maybe spam in the surrounding area. As a user like you, I would would suggest you scan the device using 173.231.200.200 for malware and patch it to prevent other people from abusing it. Once it is secured, it should automatically be unlisted.

SpamCop doesn't modify my headers. I do find it strange that your tracking URL does not contain a connection between the transcrow.online and the macports.org. Received: from localhost [127.0.0.1] by braeburn.macports.org ........something is missing here........ Received: from localhost [127.0.0.1] by m.transcrow.online That tracking URL does have the IP on a Received-SPF line, but there should also be a Received line. Received: from [80.208.228.181] (m.transcrow.online [80.208.228.181]) by braeburn.macports.org I did run across this and it maybe that braeburn.macports.org is always adding the correct headers.

A few problems with their blocking of an entire subnet is that by the time it is being blocked, the spammer has already moved on and someone else tries to honestly use it. Sometimes it has to be the honest people that need to get the attention of the ISP for them to start cracking down on spammers.

I am not having problems with mine. This could be caused by the addition of IPv6 by your ISP, or by a possible mail loop where the message happened to go through an extra internal server, or the source is the same as your ISP. A tracking URL would be helpful if you were comfortable with sharing.

I suspect the reason for this is Microsoft thinks the cloud issues need to be sent to the company's administrator. This could be a problem of cloud computing where a large company who wants to deal with their spam from their own employees want to get it directly. The downside is that smaller companies of say one individual that is the sole sender then also gets the reports.

I don't think spamassassin has a rule for the atob base64 decoding, but I added one so if I get an email that tries to use atob in the body, it should be rejected at the SMTP level. Thanks for the heads up.

I am not able to see these links. They only work with your login. If you click the links, there will be a tracking link that you can share and then we can see them.