Nyc Immunization Record Card

Problems with attachments in simscan with ripmime

In the latest version of your email server developed, which is already in production in the last three servers installed, an error appeared unusual. Basically, the content control software (simscan 1.4.0 ) was bouncing messages because it contained an attachment not allowed. The problem is striking because it does not always happen, which I quite disoriented.

I made a desperate plea for help on the mailing list tool in Inter7 site (the company that originally created the tool), but got no response, so I kept researching on my own. UPDATE: Matt Brookings, developer on simscan to Inter7 replied to my message today (10 February 2011) confirming the bug in simscan (and in ripmime, which I will report to Paul S. Daniels these days) and warning that he would review (Blog Archive the mailing list Simscan: http://news.gmane.org/gmane.mail.qmail.simscan ).

Simscan to specify a list of file extensions which will be rejected if they are attached to a message. These extensions are specified in a file called simcontrol , which then generates (by running an additional tool called simscanmk ) a database file formats CBD, containing the rules of control. The file looks like this:

: clam = yes, spam = yes, spam_passthru = yes, attach =. vbs:. Lnk:. Scr:. Cmd:. Exe,. Com,. Bat:. Reg: . pif

This basically means that the attachment with a. vbs,. lnk,. scr,. cmd. exe,. com,. bat. reg. pif is administratively prohibited. Well, the software was rejecting a file whose name happened to be "d" (yes, just the letter "D" lowercase). The strange thing is that the message had only a single attached Word file (with extension ". doc").

So you could see the error: Your email

WAS 554 Rejected Because it contains a bad attachment: d

strange thing also is that not all files. doc failed, but the problem seemed to occur in certain files only. This proved the most puzzling of all. I decided to try to review ripmime with who had earlier had an altercation on an error of layer 8 (yes, I was wrong when I installed version), and this proved to be interesting. On a copy of the message bounced ripmime ran manually and took a surprise. Ripmime removed several files (5 in total) of a message that supposedly only has a single attachment (!).

srv: / usr / local / src / ripmime-tests # mkdir res
srv:/usr/local/src/ripmime-tests # ls -la
total 140
drwxr-xr-x 4 root root 4096 Feb 8 19:29 .
drwxr-xr-x 7 root root 4096 Feb 8 16:04 ..
drwxr-xr-x 2 root root 4096 Feb 8 19:27 res
-rw------- 1 root root 125608 Feb 8 12:37 testmessage.eml
srv:/usr/local/src/ripmime-tests # ripmime --disable-qmail-bounce -i testmessage.eml -d res
srv:/usr/local/src/ripmime-tests # cd res
srv:/usr/local/src/ripmime-tests/res # ls -la
total 96
-rw------- 1 root root 90112 Feb 8 19:27 Documento de prueba.doc
-rw-r--r-- 1 root root 0 Feb 8 19:27 d
-rw-r--r-- 1 root root 0 Feb 8 19:27 textfile0
-rw-r--r-- 1 root root 8 February 1094 19:27 textfile1
-rw-r - r - 1 root root 936
February 8 19:27 textfile2

Now that I knew from where came the famous file "d", the problem was on simscan understand why he took the file as "locked" and rejected the message ... Set up a

recordio on port 25 of one of the affected servers to capture all the SMTP service transaction and enable the debugging of simscan (provided by the patch who wrote John Simpson to diagnose another problem on simscan) and then started seeing the light ...

I could get the next record:

@400000004d514dd628a87474 simscan: lpart: local part is **
@400000004d514dd628a8d61c simscan: cdb looking up gcastro@example.com
@400000004d514dd62991f5cc simscan: checking attachment textfile0 against .vbs
@400000004d514dd629921cdc simscan: checking attachment textfile0 against .lnk
@400000004d514dd629922894 simscan: checking attachment textfile0 against .scr
@400000004d514dd629923064 simscan: checking attachment textfile0 against .cmd
@400000004d514dd629923834 simscan: checking attachment textfile0 against .com
@400000004d514dd6299243ec simscan: checking attachment textfile0 against .exe
[...]
@400000004d514dd629992d74 simscan: checking attachment d against .com
@ 400000004d514dd629993544 simscan: checking attachment d against.
@ 400000004d514dd629993d14 exe simscan: checking attachment d against.
@ 400000004d514dd629997b94 bat simscan: checking attachment d against.
@ cmd 400000004d514dd629998364 simscan: [21057]: ATTACH: 5.3975s: d: 209.85.214.53: gcastrop@example2.com: gcastro@example.com
@ 400000004d514dd629998f1c simscan: exit error code: 82
400000004d514dd6299996ec @ 21057> 554 Your email WAS Rejected Because it contains a bad attachment: d 400000004d514dd722f67e2c
@ 21057 \u0026lt; ; QUIT

And so it became apparent that the file "d" fell into the rule for files extension. "cmd", which intrigued me enough, because the file name "d" differs greatly from having an extension and that extension, if any, I doubt it was. "cmd", since the file is empty ...

obvious thing of all is that. "Cmd" ends with the letter "d", which I doubted it was a coincidence ... so I started researching the simscan source. Simscan.c found that the file has a feature called check_attach () , which contains the code that compares the names with the extensions:

while ((mydirent = readdir (mydir))! = NULL) {
/ * skip. and .. * /
if ( mydirent->d_name[0] == '.' &&
(mydirent->d_name[1] == '.'
closedir (mydir);
return (1);

}}}




by another function called
str_rstr ()
, which is responsible for comparing the entries in an array of strings containing the extensions, file with the name of duty in the iteration executed sequentially on all message attachments. This function takes two parameters, the file name and extension to compare. This is the function: int


str_rstr (register char * h, register char * n)

{register char * sh;
register char * sn; for (sh = h; * h! = 0; + + h); - H;
for (sn = n; * n! = 0; + + n) - n;

for (h> = sh & & n> = sn, - h, - n) {
if (* h! =* n) {
return (-1);}


} return (0);}




As can be seen, the function reads from back to front and compare texts literally, making the problem

finally emerges. In reviewing one letter and start from back to front, when reviewing the file name "d" with the last letter of extension. "Cmd", the two match. As there is nothing left to prove, as the file name consists of a single letter, the function returns 0, so that finally the message is rejected because it contains a file is not allowed.

At this point, I had two possible solutions: either repairing the ripmime to stop extracting files do not exist, or modify the simscan source code to make an extra check on the names of files to compare with the list of extensions . I wanted to see ripmime forum to see if anyone had similar problems and discuss a possible solution, but it turned out it was closed for receiving spam, so I opt for changing the code of simscan, which I would be more simple and easy to test, not counting that could see the mailing list Inter7 meet if something unexpected.

Well, the many options that came to mind, which seemed more simple and less invasive for the code was simply check the length of file name to check in the iteration at least equal to the length of the extension to check. This would more accurately check and provide more robust software. Without thinking too much, I made the change to the code simscan.c file, adding debugging code in the same way that John Simpson did with the rest of the code to debug these errors:

for (i = 0; i \u0026lt; MaxAttach; + + i) { if ( DebugFlag > 2 ) fprintf(stderr, "simscan: checking attachment %s against %s\n", mydirent->d_name, bk_attachments[i] );
lowerit(mydirent->d_name);

if ( strlen(mydirent->d_name) >= strlen(bk_attachments[i]) ) {

if ( str_rstr(mydirent->d_name,bk_attachments[i]) == 0 ) {
strncpy(AttachName, mydirent->d_name, sizeof(AttachName)-1);

closedir(mydir);
return(1);
}
} else { if ( DebugFlag > 2 ) fprintf(stderr, "Simscan: attachment name '% s' (% d) is Shorter than '% s' (% d). IGNORED \\ n", mydirent-> d_name, strlen (mydirent-> d_name) bk_attachments [i] strlen (bk_attachments [i]));
}}




Now if the long file name to check is less than the length of the extension, simply ignores simscan:

[...]
@ 400000004d517ee02c8894d4 simscan: attachment name d (1) is Smaller than. vbs (4)
@ 400000004d517ee02c895054 simscan: checking attachment d against.

@ cmd 400000004d517ee02c8a0fbc simscan: attachment name d (1) is Smaller than. cmd (4)
@ 400000004d517ee02c8acb3c simscan: checking attachment d against. lnk
@ 400000004d517ee02c8b8aa4 simscan: attachment name d (1) is Smaller than. lnk (4)

[...] And simscan longer fails with cryptic error that triggered this entertaining session debugging.

hereby released this patch, which left here for anyone who wants to use it:


simscan-1.4.0/simscan.c simscan-1.4.0-tested/simscan.c diff-run simscan-

--- 08/02/2011 1.4.0/simscan.c
20:26:06.095067924 -0200 + + + simscan-1.4.0-tested/simscan.c
08/02/2011 18:16:11.003064430 -0200 @ @ - 1735.10
+1735,14 @ @ for (i = 0; i
if (DebugFlag > 2 ) fprintf(stderr, "simscan: checking attachment %s against %s\n", mydirent->d_name, bk_attachments[i] );
lowerit(mydirent->d_name);
- if ( str_rstr(mydirent->d_name,bk_attachments[i]) == 0 ) {

- strncpy(AttachName, mydirent->d_name, sizeof(AttachName)-1);
- closedir(mydir);
- return(1);
+ if ( strlen(mydirent->d_name) >= strlen(bk_attachments[i]) ) {
+ if ( str_rstr(mydirent->d_name,bk_attachments[i]) == 0 ) { + strncpy(AttachName, mydirent->d_name, sizeof(AttachName)-1);
+ closedir (mydir);
+ return (1);

+} +} else {
+ if (DebugFlag> 2) fprintf (stderr, "simscan: attachment name '% s' (% d) is Shorter Than '% s' (% d). IGNORED \\ n ", mydirent-> d_name, strlen (mydirent-> d_name) bk_attachments [i], strlen (bk_attachments [i]));

}}}




should be noted that this patch is intended to be applied to the patch 1.4.0 simscan
http://qmail.jms1.net/simscan/simscan-1.4.0-combined.4.patch

of John Simpson ( Thanks, John!)
.

Well, one less ... to continue with the others.

Happy hacking!