On Mon, 24 Jul 2017 23:00:33 +0100, Alex wrote:
Link to malicious file removed... Generally not a good idea to post direct
links like that.
What would be involved in following these links in SA to determine if
they immediately download a file (other than a web page)?
Testing links in mail
On Mon, 24 Jul 2017 18:00:33 -0400
Alex wrote:
> This one's probably already on some blacklists, but I'm still
> blocking others:
>
> https://pastebin.com/p7EnFNf7
It seems to be common for this kind virus spam to pass itself off as an
invoice. You might try creating a rule that checks for this
On Tue, 25 Jul 2017 13:15:33 +0100
RW wrote:
> https://pastebin.com/p7EnFNf7
We've seen lots of those and collected a few dozen unique URLs for our
URL blacklists. I added a swath of them to the APER project in this
commit:
https://sourceforge.net/p/aper/code/11830/
All of the URLs ma
On Tue, 25 Jul 2017, Rupert Gallagher wrote:
Before bothering with body spam, make sure the header is clear. The
specific email should have been rejected upfront, because the foreign
sender's message-id pretends to originate from the recipient's smtp
server.
That's potentially valid. If a MT
On Tue, 25 Jul 2017 10:28:41 -0500 (CDT)
David B Funk wrote:
> If the original message actually had that message-ID form when it
> arrived at the OP's mail MX server, then your assessment makes sense.
>
> However it's entirely possible that message-ID was added by the OP's
> mail server because t
On Tue, 25 Jul 2017 09:43:04 -0600
The Doctor wrote:
> Suddenly overnight, spamassassin died on one of my FreeBSD servers
> and attempts to get it back up are failing.
> root@gallifrey:~ # ps axww | egrep spamd
> 97595 - Rs 0:09.86 /usr/local/bin/perl -T
> -w /usr/local/bin/spamd -u spamd
On Tue, Jul 25, 2017 at 11:24:21PM +0100, RW wrote:
> On Tue, 25 Jul 2017 09:43:04 -0600
> The Doctor wrote:
>
> > Suddenly overnight, spamassassin died on one of my FreeBSD servers
> > and attempts to get it back up are failing.
>
> > root@gallifrey:~ # ps axww | egrep spamd
> > 97595 - Rs
+1 to remove that clause from the RFC.
When a mail arrives without mid, either the sender did not use a real SMTP
server or tried to hide it. We have a custom SA rule for it. We also reject
upfront any mid with a syntax error, or whose domain does not have a rdns (eg.
@localhost.localdomain or @