Hi, I'm getting an increasing number of spams with attachments that have the .pif extensions. I know they can not harm me (not in Linux), but I would like somehow to not download them (they are a 100 Kbytes each). I'm using fetchmail, postfix, procmail, spamassassin and AMaViS (which doesn't detect them, by the way). All of it from the default SuSE 8.2 with you patches. I'm thinking, perhaps, of some thing in /etc/postfix/header_checks, or something else perhaps. It is only needed for one address. I think it has beeing commented here, but I can not remember it now. Perhaps I'm tired tonight :-) [...] It is even worse. Now I'm getting autoresponses form postmasters. One complains that I sent a subscriber the virus "W32/Sobig.f@MM" - which I didn't, the headers returned says I used outlook X-) . Another postmaster autoreject complains that the recipient box is full - and returns to me the 100Kb attachment. Heck. Who configured that, I wonder? Have a look: X-MailScanner: Found to be clean <----------------- Ha, jeh! X-) Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 -- Cheers, Carlos Robinson
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 4 Sep 2003 01:51:24 +0200 (CEST) "Carlos E. R." <robin1.listas@tiscali.es> wrote:
I'm thinking, perhaps, of some thing in /etc/postfix/header_checks, or something else perhaps. It is only needed for one address.
I haven't done this myself, but I think you can set up "content filtering" in Postfix. Charles - -- "If you want to travel around the world and be invited to speak at a lot of different places, just write a Unix operating system." (By Linus Torvalds) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/VoaL3epPyyKbwPYRAndQAJ9Kk4iyGoEQVvBXpmOaxu+tHXpONwCcDZwd XVQQGwJ+nUHV2gy8wEnCu2o= =l8U7 -----END PGP SIGNATURE-----
On 09/04/2003 07:51 AM, Carlos E. R. wrote:
I'm getting an increasing number of spams with attachments that have the .pif extensions.
That is the Sobig.F virus. Like you said, it won't infect you, just tie up bandwidth.
I'm using fetchmail, postfix, procmail, spamassassin and AMaViS (which doesn't detect them, by the way). All of it from the default SuSE 8.2 with you patches.
Do you have antivir installed? AMaViS is just a program to pipe the mail through an antivirus program. I am using Anitvir for scanning email, having it update once a day through cron, and it has picked up this virus at least one a day for one user all week.
It is even worse. Now I'm getting autoresponses form postmasters. One complains that I sent a subscriber the virus "W32/Sobig.f@MM" - which I didn't, the headers returned says I used outlook X-) .
One of the characteristics of this virus, it spoofs the sender. You know you didn't send it, whoever did had your address in their machine, either address book or internet cache.
Another postmaster autoreject complains that the recipient box is full - and returns to me the 100Kb attachment. Heck. Who configured that, I wonder?
An amazing waste of bandwidth...
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
I didn't come from you. -- Joe Morris New Tribes Mission Email Address: Joe_Morris@ntm.org Web Address: http://www.mydestiny.net/~joe_morris Registered Linux user 231871 God said, I AM that I AM. I say, by the grace of God, I am what I am.
The 03.09.04 at 08:26, Joe Morris (NTM) wrote:
I'm getting an increasing number of spams with attachments that have the .pif extensions.
That is the Sobig.F virus. Like you said, it won't infect you, just tie up bandwidth.
Right... it is filling up my box, though. And I pay by the minute of connection :-(
I'm using fetchmail, postfix, procmail, spamassassin and AMaViS (which doesn't detect them, by the way). All of it from the default SuSE 8.2 with you patches.
Do you have antivir installed? AMaViS is just a program to pipe the mail through an antivirus program. I am using Anitvir for scanning email, having it update once a day through cron, and it has picked up this virus at least one a day for one user all week.
Ah... then I'll have to update it. The problem is that I would like the reject to happen as soon as postfix or whatever knows there is an attachement with "*.pif" in it, and abort the download. Amavis checks it after it is downloaded, I think.
One of the characteristics of this virus, it spoofs the sender. You know you didn't send it, whoever did had your address in their machine, either address book or internet cache.
I know...
Another postmaster autoreject complains that the recipient box is full - and returns to me the 100Kb attachment. Heck. Who configured that, I wonder?
An amazing waste of bandwidth...
Indeed! It is so, yes. Their servers must be smoking. I wish servers would do virus check, and spam check, as routine.
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
I didn't come from you.
X-) Of course not! That is the proof, precissely ;-) -- Cheers, Carlos Robinson
The 03.09.04 at 01:51, Carlos E. R. wrote:
I'm getting an increasing number of spams with attachments that have the .pif extensions. I know they can not harm me (not in Linux), but I would like somehow to not download them (they are a 100 Kbytes each).
According to the sdb (Support knowledgebase (rsimai_slox_anti_spam)), the body of a message can be filtered using "/etc/postfix/body_checks", and enabling "body_checks" in "/etc/postfix/main.cf". It is in fact easier than that, according to the "RELEASE_NOTES": [Feature 20020527] Postfix now has three classes of header patterns: header_checks (for primary message headers except MIME headers), mime_header_checks (for MIME headers), and nested_header_checks (for headers of attached email messages except MIME headers). By default, all headers are matched with header_checks. Therefore, including this line in "/etc/postfix/header_checks" /(filename|name)=".*\.(pif)"/ REJECT is sufficient. The sample has this other one, more extensive: /(filename|name)=".*\.(asd|chm|exe|doc|dll|hlp|hta|js|ocx|pif)"/ REJECT The only snag is that the rejection is only logged, I receive no email warning of the fact. I would prefer postfix to send me (not the originator) an email including the headers of the rejected email. I have tested the above locally. Now I will go online and see what happens :-) -- Cheers, Carlos Robinson
The 03.09.04 at 13:49, Carlos E. R. wrote:
I have tested the above locally. Now I will go online and see what happens :-)
Well, there is another little snag: fetchmail reports to the originator: Sep 4 13:53:25 nimrodel fetchmail[4785]: SMTP>. (EOM) Sep 4 13:53:26 nimrodel fetchmail[4785]: SMTP< 550 Error: Message content rejected Sep 4 13:53:26 nimrodel fetchmail[4785]: SMTP error: 550 Error: Message content rejected Sep 4 13:53:26 nimrodel fetchmail[4785]: SMTP< 220 nimrodel.valinor ESMTP Postfix Sep 4 13:53:26 nimrodel fetchmail[4785]: SMTP> HELO localhost Sep 4 13:53:26 nimrodel fetchmail[4785]: SMTP< 250 nimrodel.valinor Sep 4 13:53:26 nimrodel fetchmail[4785]: SMTP> MAIL FROM:<FETCHMAIL-DAEMON@nimrodel.valinor> Sep 4 13:53:26 nimrodel fetchmail[4785]: SMTP< 250 Ok Sep 4 13:53:26 nimrodel fetchmail[4785]: SMTP> RCPT TO:<XXXXXX@hotmail.com> Sep 4 13:53:26 nimrodel fetchmail[4785]: SMTP< 250 Ok Sep 4 13:53:26 nimrodel fetchmail[4785]: SMTP> DATA Sep 4 13:53:26 nimrodel fetchmail[4785]: SMTP< 354 End data with <CR><LF>.<CR><LF> Sep 4 13:53:26 nimrodel fetchmail[4785]: SMTP: (bounce-message body) Sep 4 13:53:26 nimrodel fetchmail[4785]: SMTP>. (EOM) And it is indeed sent to the originator, and accepted by his server: Sep 4 13:53:26 nimrodel postfix/qmgr[4170]: 8A73429F55: from=<FETCHMAIL-DAEMON@nimrodel.valinor>, size=1691, nrcpt=1 (queue activeSep 4 13:53:26 nimrodel fetchmail[4785]: SMTP< 250 Ok: queued as 8A73429F55 Notice that my from address is absolutely bogus, invented! Nice checking by the receiver host ;-) By the way, this means that "set no spambounce" in .fetchmailrc doesn't work for this. Perhaps I could use "-nobounce", but it would affect all bounces: The --nobounce option suppresses the normal action of bouncing errors back to the sender in an RFC1894-confor mant error message. If nobounce is on, the message will go to the postmaster instead. Whose postmaster? Me, or the originator server? -- Cheers, Carlos Robinson
* Carlos E. R.; <robin1.listas@tiscali.es> on 04 Sep, 2003 wrote:
Therefore, including this line in "/etc/postfix/header_checks"
/(filename|name)=".*\.(pif)"/ REJECT
I am using DISCARD which silently throws away the email no bounce messages to anyone :-) ps look to this site the contributions have a lot of UCE code :-) http://www.hispalinux.es/%7Edata/postfix/ -- Togan Muftuoglu Unofficial SuSE FAQ Maintainer http://dinamizm.ath.cx
The 03.09.04 at 18:06, Togan Muftuoglu wrote:
/(filename|name)=".*\.(pif)"/ REJECT
I am using DISCARD which silently throws away the email no bounce messages to anyone :-)
Mmmm... I didn't see that one. Ah, found it in sample-filter.cf: # DISCARD [optional text...] # Claim successful delivery and silently discard the message. # The matched header is logged with the optional text. There is a "but", then. From that doc, fetchmail is not informed, and will keep downloading it, wasting my good bandwidth and connection time. In my case, I prefer reject, which stops fetchmail in mid track. Discard may be useful with a permanent network connection, but not a limited bandwidth modem connection, paying by the minute to the phone company. The sequence is this: Fetchmail starts downloading a message - watch the from ;-) I have obscured the "victim": Sep 4 19:58:10 nimrodel fetchmail[3924]: POP3> RETR 75 Sep 4 19:58:10 nimrodel fetchmail[3924]: POP3< +OK 101132 bytes Sep 4 19:58:10 nimrodel fetchmail[3924]: reading message XXXXXX@xxx.tiscali.es:75 of 81 (101132 octets) smtp connection to postfix opened, fetch starts: Sep 4 19:58:11 nimrodel fetchmail[3924]: SMTP> MAIL FROM:<sXXXput@microsoft.com> SIZE=101132 Sep 4 19:58:11 nimrodel fetchmail[3924]: SMTP< 250 Ok Sep 4 19:58:11 nimrodel fetchmail[3924]: SMTP> RCPT TO:<cer@localhost> Sep 4 19:58:11 nimrodel fetchmail[3924]: SMTP< 250 Ok Sep 4 19:58:11 nimrodel fetchmail[3924]: SMTP> DATA Sep 4 19:58:11 nimrodel fetchmail[3924]: SMTP< 354 End data with <CR><LF>.<CR><LF> Postfix, which was called by fetchmail, detects the header, and rejects it, within one second: Sep 4 19:58:11 nimrodel postfix/cleanup[3942]: 1E6ECCAA36: message-id=<3EF2DB990085B00F@pop4.es.tisadm.net> (added by postmaster@nettmail.tiscalinet.es) Sep 4 19:58:11 nimrodel postfix/cleanup[3942]: 1E6ECCAA36: reject: header Content-Type: application/octet-stream;??name="movie0045.pif" from localhost[127.0.0.1]; from=<sXXXput@microsoft.com> to=<cer@localhost.nimrodel.valinor> proto=ESMTP helo=<localhost>: Message content rejected Sep 4 19:58:11 nimrodel postfix/local[4758]: 88386CAA22: to=<FETCHMAIL-DAEMON@nimrodel.valinor>, relay=local, delay=0, status=bounced (unknown user: "fetchmail-daemon") (The last line refers to another email, they are interleaved; I have just added "fetchmail-daemon: postmaster" to my "/etc/aliases", so that I get the bounce-bounced: I'm curious) 14 seconds later, fetchmail stops downloading it; that's about 55 Kbytes maximum (the payload has a hundred). I'm not fully sure how much it has downloaded, but I would prefer it to act faster. Sep 4 19:58:35 nimrodel fetchmail[3924]: SMTP>. (EOM) Sep 4 19:58:36 nimrodel fetchmail[3924]: SMTP< 550 Error: Message content rejected Sep 4 19:58:36 nimrodel fetchmail[3924]: SMTP error: 550 Error: Message content rejected Sep 4 19:58:36 nimrodel postfix/smtpd[3971]: connect from localhost[127.0.0.1] And fetchmail now tries to generate a bounce mail, handed over to my postfix daemon: Sep 4 19:58:36 nimrodel fetchmail[3924]: SMTP< 220 nimrodel.valinor ESMTP Postfix Sep 4 19:58:36 nimrodel fetchmail[3924]: SMTP> HELO localhost Sep 4 19:58:36 nimrodel fetchmail[3924]: SMTP< 250 nimrodel.valinor Sep 4 19:58:36 nimrodel postfix/smtpd[3971]: 0EB09CAA22: client=localhost[127.0.0.1] Sep 4 19:58:36 nimrodel fetchmail[3924]: SMTP> MAIL FROM:<FETCHMAIL-DAEMON@nimrodel.valinor> Sep 4 19:58:36 nimrodel fetchmail[3924]: SMTP< 250 Ok Sep 4 19:58:36 nimrodel fetchmail[3924]: SMTP< 250 Ok Sep 4 19:58:36 nimrodel fetchmail[3924]: SMTP> RCPT TO:<sXXXput@microsoft.com> Sep 4 19:58:36 nimrodel fetchmail[3924]: SMTP< 250 Ok Sep 4 19:58:36 nimrodel fetchmail[3924]: SMTP> DATA Sep 4 19:58:36 nimrodel fetchmail[3924]: SMTP< 354 End data with <CR><LF>.<CR><LF> Sep 4 19:58:36 nimrodel fetchmail[3924]: SMTP: (bounce-message body) Sep 4 19:58:36 nimrodel fetchmail[3924]: SMTP>. (EOM) Sep 4 19:58:36 nimrodel postfix/cleanup[3978]: 0EB09CAA22: message-id=<20030904175836.0EB09CAA22@nimrodel.valinor> Sep 4 19:58:36 nimrodel postfix/qmgr[2842]: 0EB09CAA22: from=<FETCHMAIL-DAEMON@nimrodel.valinor>, size=1694, nrcpt=1 (queue active) Sep 4 19:58:36 nimrodel fetchmail[3924]: SMTP< 250 Ok: queued as 0EB09CAA22 Sep 4 19:58:36 nimrodel postfix/smtpd[3971]: disconnect from localhost[127.0.0.1] And then fetchmail deletes the email from the server: Sep 4 19:58:36 nimrodel fetchmail[3924]: SMTP> QUIT Sep 4 19:58:36 nimrodel fetchmail[3924]: SMTP< 221 Bye Sep 4 19:58:36 nimrodel fetchmail[3924]: SMTP listener refused delivery Sep 4 19:58:36 nimrodel fetchmail[3924]: SMTP> RSET Sep 4 19:58:36 nimrodel fetchmail[3924]: SMTP< 250 Ok Sep 4 19:58:36 nimrodel fetchmail[3924]: flushed Sep 4 19:58:36 nimrodel fetchmail[3924]: POP3> DELE 75 Sep 4 19:58:36 nimrodel fetchmail[3924]: POP3< +OK message marked for deletion And starts fetching the next one: Sep 4 19:58:36 nimrodel fetchmail[3924]: POP3> RETR 76 Sep 4 19:58:36 nimrodel fetchmail[3924]: POP3< +OK 4272 bytes Finally, postfix tries to send the bounce: Sep 4 19:58:36 nimrodel postfix/smtpd[3949]: 873FDCAA31: client=localhost[127.0.0.1] Sep 4 19:58:36 nimrodel postfix/cleanup[3942]: 873FDCAA31: message-id=<20030904175836.0EB09CAA22@nimrodel.valinor> Sep 4 19:58:36 nimrodel postfix/qmgr[2842]: 873FDCAA31: from=<FETCHMAIL-DAEMON@nimrodel.valinor>, size=1917, nrcpt=1 (queue active) Sep 4 19:58:36 nimrodel postfix/pipe[3943]: 0EB09CAA22: to=<sXXXput@microsoft.com>, relay=vscan, delay=0, status=sent (nimrodel.valinor) And succeeds. See? Microsoft hasn't checked the sender domain ;-)
ps look to this site the contributions have a lot of UCE code :-)
Not bad... But I prefer leaving my spam filtering to spamassassin - except if they are big. I have some addresses blocked, and they keep trying. -- Cheers, Carlos Robinson
On Thursday 04 September 2003 01:51, Carlos E. R. wrote:
Have a look:
X-MailScanner: Found to be clean <----------------- Ha, jeh! X-)
that's a great header to filter by. the virus adds exactly that line to fool... hum, well, I don't know who's that supposed to fool. :) regards, Hansen -- Powered by SuSE 8.1pro - KDE 3.0.3 - KMail 1.4.3 At least, try asking smart questions: http://www.catb.org/~esr/faqs/smart-questions.html "Microsoft isn't the answer. Microsoft is the question, and the answer is NO." - Anon
The 03.09.04 at 16:11, Johannes Liedtke wrote:
On Thursday 04 September 2003 01:51, Carlos E. R. wrote:
Have a look:
X-MailScanner: Found to be clean <----------------- Ha, jeh! X-)
that's a great header to filter by. the virus adds exactly that line to fool... hum, well, I don't know who's that supposed to fool. :)
Maybe the "X-MailScanner" program itself is fooled by it, thinking that he already scanned it. I was thinking yesterady that SpamAssassin does that, and wondered if there is a switch to make it ignore his own headers, and scan again. -- Cheers, Carlos Robinson
participants (5)
-
Carlos E. R. -
Charles Philip Chan -
Joe Morris (NTM) -
Johannes Liedtke -
Togan Muftuoglu