Recent content by mxroute

I'm looking for feedback from other users who have their servers upgraded to SpamAssassin 4.0. You can tell by this: root@moose:/var/log# spamassassin -V SpamAssassin version 4.0.0 On servers upgraded to SA 4.0, our /var/log/maillog (or /var/log/mail.log) is filled with tons of log entries...

That the rule is deprecated and will later be replaced by another is not something you have to worry about. That spam senders are on your user's SpamAssassin whitelist seems to be the relevant problem in this case.

The solution is to develop a new standard for email and get all of the stakeholders to sign off on it. I don't doubt that you can do it, but you should be aware that the scope of this involves getting support from Google, Microsoft, and a very large surrounding community. People have spent much...

If you're concerned that your PHP code allows third parties to spoof senders and use your software to do it, then the answer would be to use more secure PHP code. Don't reinvent the wheel: https://github.com/PHPMailer/PHPMailer If you're concerned that anyone sending mail at any time can spoof...

While that was always one of my concerns with this activity, I just don’t think the pieces fit to show that they were exploiting anything. You just can’t silently relay that many emails through our servers without every one of us standing up and saying “Why am I getting abuse complaints for spam...

That’s a feature of spamhaus though and not an issue with their DNS resolvers. https://www.spamhaus.com/resource-center/successfully-accessing-spamhauss-free-block-lists-using-a-public-dns/ Fairly certain you know that already, just adding clarity for others sake 💜

Only if your customers don't mind not sending/receiving email or you feel like replacing exim in the DA stack real quick. Typically these things don't see so much interest prior to any usable information being available.

Last time I checked deeply it was: - 96 recipients per IP, IP never seen twice - mostly the same .ru and .cz sender domains with the occasional addition to their sender domain list - Never, EVER, targeted to a server that actually houses the recipient domain. Never. Not once, that I saw. BUT...

It's definitely the same botnet and same activity that I've been tracking for a few months, so I'm at least a little bit ahead of you on this but I still don't have the whole thing wrapped up in a nice package with a full conclusion. Since you're not relaying one server through the other, I'm...

Is that server configured to relay mail through the server you caught the log on? It could just be a logging issue that you don't see it on the 95.* server. Exim does a strange thing when configured to relay mail through another server, it'll actually open a connection with the relay and declare...

Is the 95.* IP your server or just the hostname? Because if it's not your IP then how they do this is very easy: "HELO server.companyhostname.nl"

I run an entire email service with a total of 484,410 email accounts, going since 2013, and I have never once run into this issue. I would tell them something like "We use Exim, a standards-compliant email server with proper configuration. Please have your sender adjust their configuration as...

Are you sure this isn't a problem with their mail server? You said this is when you send email to them, your server reports back that their server doesn't support a necessary protocol, right? That's how I'm reading it.

Rsync their maildir directories.

There's email forwarding happening there isn't there? If so, this is normal. The answer is don't use email forwarders if you need the end result to look professional. Because you would in fact be receiving it via the original recipient domain that forwarded it. If I've properly understood the...