Topic: getting hammered by .pdf attachments

[idyll]

I am seeing a new SPAM technique, the attached .pdf file. Though training the system religiously, perhaps 30% of these are making it through SA, etc.

Anyone else seeing this new deluge? Any tricks or filters I am missing? I see no way to block this particular (and useful, sadly) attachment type in the the web GUI.

thanks

regards,

patrick

[bpivk]

Got the same spam mail today. I didn't train the bayess filter yet but i hope that it will block it. Note that this is the first spam mail that i got.

[raem]

idyll

> I see no way to block this particular (and useful, sadly) attachment type in the the web GUI. (ie pdf)

See my old Howto which is not required for installing to sme7 as the functionality is built in. You can use the other information in the Howto to analyse & create a new "pattern/signature/magic" for pdf files & enter it in the mailpatterns db in /home/e-smith/db as that part is still applicable to sme7.
See the section from "Analyzing and creating patterns" onwards (about half way through) as all/most of that is still applicable.

http://mirror.contribs.org/smeserver/contribs/rmitchell/smeserver/howto/Virus%20and%20file%20blocking%20HOWTO%20using%20smtpfront-qmail%20for%20sme%20server.htm

[stephen noble]

please attach the signature for a pdf to a bug for consideration to be added to the base

because pdf is generally useful it would be disabled, but you'd have to option to enable

[gregswallow]

The fuzzyocr guys (just one guy actually) is working on pdf support in an upcoming version.  You could keep an eye on the progress here:
http://fuzzyocr.own-hero.net/log/trunk

It says "highly experimental", so probably not quite ready yet...

[idyll]

Thanks for the information. I am disinclined to invoke a "block all" option as .pdf is useful and not uncommon for valid email.

I am sure integrating this with the fuzzy OCR logic is not trivial. I have been extremely pleased with the fuzzy option thus far, so I remain optimistic it can be made to include rejection of bogus .pdf.

Having said that, I feel better knowing others are also seeing this new wave of blight. The ebb and flow of SPAM is now on a gradual upswing so it seems to be time to tighten things down a bit more.

regards,

patrick

[gregswallow]

You could see if this helps:
http://mirror.contribs.org/smeserver/releases/7.1/smedev/i386/RPMS/spamassassin-botnet-0.7-1.el4.sme.noarch.rpm

I haven't been using it, so I'm not sure how well it works or doesn't work.  Report any problems to the bug tracker.

[mmccarn]

After dumping 3 or 4 of these pdf attachments into my 'LearnAsSpam' folder for bayes processing I don't get them any more.

Are you doing anything to train your bayes filters?  I have done this:[list=a]

• Set my server up mostly according to the Sonoracomm howto
  
• created my IMAP 'LearnAsSpam' folder
• customized /usr/bin/LearnAsSpam.pl to have no output if the LearnAsSpam folder is empty
  
• modified /etc/cron.d/LearnAsSpam.cron to run the script every 15 minutes instead of daily.
  
• created and scheduled LearnAsHam.pl based on LearnAsSpam.pl to let me easily mark email as Ham when necessary.[/list:o]

[gregswallow]

After dumping 3 or 4 of these pdf attachments into my 'LearnAsSpam' folder for bayes processing I don't get them any more.

Can you maybe update this bug report on the same subject - it has been sitting there a year:
http://bugs.contribs.org/show_bug.cgi?id=1701 - It sounds like a good feature to have in the base.

Thanks,

[mmccarn]

Modified scripts, cron files and installation instructions posted to http://bugs.contribs.org/show_bug.cgi?id=1701

[idyll]

thanks for posting the enhancements to this suite of tools.

I did need to chmod 644  all four of the items, the two .crons and the two .pls.  They were reflecting (*system*) BAD FILE MODE in the logs. FYI.

They are running nicely, and as my SPAM has gone up 3x in the last week or so, this aggressive countermeasure is well worth the effort.

regards,

patrick

[gregswallow]

I did need to chmod 644  all four of the items, the two .crons and the two .pls.  They were reflecting (*system*) BAD FILE MODE in the logs. FYI.

Please update the bug report with that info.


I found another option to try - I made a bug report here about it:
http://bugs.contribs.org/show_bug.cgi?id=3172

[idyll]

Bug updated.

[mmccarn]

I did not have to do any 'chmod'ing on my test system.

I ran the listed commands (curl -o blah-blah-blah) as root.  Did you download the files as root?

ALso, the scheduled cron jobs don't try to 'execute' the scripts, but instead execute 'perl' using the script as an argument.

Or am I just missing the point?

[idyll]

I downloaded and ran the scripts as root. I found the permissions to be set to 755 after they failed to run, and the cron logs reflect what I reported.

I changed the four files to 644 and the errors left, and everything is running properly.

I was previously running the "learn" perl script - it was I who posted it as a solution for 7.xx after trading email with Jesper and receiving his permission to do so.  Multiple others tweaked it to work with 7.xx, It has been working ever since and I have not touched the permissions or ownerships. I downloaded your installer/scripts and hence, the log reports.

I posted it here as I did not suspect it was a bug, but something odd. I was advised to enter it on your bug. So I did. Should we continue this dialog here or there? Beats me.

The point was I saw the logs and reported what I saw. Was there another point to be made other than you correcting my syntax?

patrick