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!

Overdosing On Zopiclone Fatal

It Hot In chones

Among the familiar uniform of my relatives, an aunt succeeded in distinguishing a gift occasionally possesses contagious but always fascinating: he knows perfectly the scheduling of every one of the social so many magazines that circulate in Aguascalientes, knows for sure when dawn each of these publications in the garage of their home. For good measure, his talent for memorizing dates is that browsing these publications has become part of daily life. I doubt

peculiar hobby of my own aunt is a hobby exclusively, to check, before the lamentable lack of reliable data on the flow and circulation of print media at the local level, I take the liberty to apply the frivolous sociology of facebook. One of these publications, The Board, has more fans than El Heraldo and La Jornada Aguascalientes, a third day ( The hidrocálido ) publishes a Sunday supplement called very special social events , which does not have many followers as the papers mentioned above. My aunt, apparently, not alone, shares his hobby with a few non-aquicalidenses.

The fascination sparked by such magazines is a strange phenomenon, I was difficult to decipher the source of his popularity. These publications do not provide significant information to its readers, are clenched insipid propaganda, are inefficient and photographic evidence and portray events whose importance in a city inhabited by commoners I fail to conceive beyond a small circle of regular people to the events of the cream of our society, at least in the Hello! are portrayed blue blood. The only saving grace that emerges from them seems to be that of the pose, the sitters are invited to pose for the photo, give their consent, smile and leave his presence embodied in this or that social event, in short, give a nod to the Society welcomes your reading, revealing the Aguascalientes fascination with appearance.

In one of his essays, Carlos Monsivais suggests that readers of publications such illusions cast their regular consumption of photos and notes "the aristocracy of blood and the aristocracy of money." Is that the case of my aunt and thousands of aquicalidenses?

hidrocálido society living under the yoke dictated by the appearance, it will appeal to the ease of classism, this phenomenon is not exclusive to the privileged social classes or the frivolous magazines who are eager to portray the phenomenon occurs in abundance: dilapidated houses inside but with a new car in the garage, professionals without a penny in the portfolio but with an iPhone in my pocket, bicicálidos attending Tuesday's shot but the rest of the week moving in particular automotive ... even in reverse there are many visitors as part of the festival sanmarqueña, I have commented on their surprise at the exotic extravagance and excessive wearing the popular classes in Aguascalientes, just as likely to appear as cholos - "in the de-Efe race is only worried about dancing cumbias "-.

a couple of weeks ago I read an interesting news story: a group of about two hundred people will bet to lighten, to this end, they decided to embark on a journey into the capital's subway, with the notable peculiarity that made him ... in his underwear! . Of course, this act was not spontaneous but planned, "any act of magic, after all, is a trick- and was done with a noble goal: to provide the busy capital city for a moment of hilarity to be relax and forget for a moment the monotony of the routine.

An act of this nature is missing in society hidrocálido, a shameless entertainment that allows rid of that false dictated by the looks, let's pose for a moment, cast off the starched shirt, dropping our jeans, pull the basket Carolina Herrera fragrance, to hell with the show ... which are complex, exposing the swollen abdomen, sagging breasts, a prominent scar and the entire sum of our imperfections ... that vanity wait in the closet, after all, as I told Joe E. Brown Jack Lemmon: "Nobody is perfect."

So ... when we go to wood in piglets? ... one of these, chance and to go out on the cover of the Black and White .