> -----Original Message----- > From: Alex van den Bogaerdt
> On Thu, Sep 18, 2003 at 12:42:15AM -0400, Larry Gilson wrote: > > Hi Alex, > > > > in master.cf: > > > > > > spamc unix - n n - - > pipe > > > flags=Fq > > > user=spamcheck > > > argv=/usr/bin/spamc -x -e /usr/sbin/sendmail -i -f > > > $sender $recipient > > > This solution is simple and probably provides the best > > performance of all the options. However, it provides no error > > checking nor backup. I check to see if the message passed through > > spamc, if not I run it through spamassassin. And as Jim pointed > > out from the spamc man page, using the -e option has a slight > > chance of loosing mail. > > Thanks for answering Larry. > > I'm under the impression that I could safely use "-e" because > I also use "-x": > > "Don't use the 'safe fallback' error-recovery method, which passes > through the unaltered message if an error occurs. Instead, exit > with an error code, and let the MTA queue up the mails for a retry > later. " > > In other words: I expect that postfix will handle the cases > where spamc gets into trouble. Are you saying this isn't true? If my understanding is not right, I would appreciate it if someone could correct me. As always, I could be wrong. My interpretation is that Postfix will deliver the message via a pipe to spamc on STDIN. After the message is written to spamc, Postfix considers the message delivered and does not read a result back from spamc - which is why reinjection by sendmail is needed. I believe that the read portion of this pipe is just to determine success or failure in writing the message to spamc. spamc will spool the message to spamd, read the resulting message back and then pipe (-e option) the message to sendmail. If fork-and-exec fails in delivering to sendmail, spamc has no place to put the message and the message will be lost. The process of delivering to sendmail is well beyond Postfix's ability to salvage the message and place it in the deferred queue. spamc will return an error message which should be logged in the maillog but that will be just a notification. I think that the place in which Postfix could defer the message is if spamc could not communicate with spamd. In the "Simple content filter limitations" section of the FILTER_README, Wietse (or whoever the author is) outlined potential pitfalls with the shell script that is also used by SecuritySage. A problem, such as a memory allocation problem, may not produce a nice exit code and could result in bounced messages. I think this area makes the use of Procmail advantageous. Procmail pipes to spamc so it will receive messages and errors from spamc directly. Procmail has the ability to salvage the message and continue processing. Procmail will then deliver the message to sendmail directly rather than have spamc or shell script deliver it. Again, I would appreciate correction where needed. --Larry ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
