On Tue, 7 May 2002, Gilles Nedostoupof wrote: I rewrote your message into RFC2822 compliance; please reply *below* the body text and *quote* existing text when replying. Your message was impossible to reply to as delivered. :/
>> Daniel Pittman [mailto:[EMAIL PROTECTED]] wrote: >> On Tue, 7 May 2002, Gilles Nedostoupof wrote: >>> I'm using Spamassassin 2.20 (spamd / spamc / procmail) with Postfix >>> 1.1.8 on a mail gateway to filter incoming emails. All is then >>> redirected to an exchange server elsewhere on the network. >>> >>> My problem is that when someone is requesting a "delivery receipt for >>> this message" into Outlook, when the recipient receive the message, >>> the "delivery receipt" is sended to the user who run spamd (eg: >>> nobody) and not to the original sender. >> >> What is the syntax that you are using when you reinject the mail into >> the Postfix system? >> >> My presumption is that you are simply piping the message to >> sendmail(1), resulting in the SMTP sender being set incorrectly. >> >> Try using something like: >> >> ... | spamc | sendmail -i <original SMTP address> >> >> How you determine the original address when using Procmail is beyond >> me, though, as I don't use procmail in my setup. > > In my alias file for postfix; I'm using something like > > Alias: "| procmail -a \"user@msexchange\"" So, this delivers locally, through a procmail script, junking the original sender in the process... > Here's the content of my /etc/procmailrc [...] > :0 > ! $1 ...and this finally sends a new email with the same content to the original recipient, created by the spam filtering user. When you disabled SpamAssassin in the setup you removed the call out to procmail as well, didn't you? > The configuration is working fine... Except for the "delivered > receipt" Sure, because the SMTP envelope is hidden from the people reading the email. The server, though, is not going to do the right thing in this case because the email it gets *is* from the user running SpamAssassin. The best way to fix this, and to get a very nice boost in performance into the bargain, is going to be to use the integrated filtering abilities of Postfix. So, start by reading the FILTER_README that came with Postfix. This will improve your life because then you will understand how to do this. Configure the spam filter as: # Add my local content filter... spam unix - n n - - pipe flags=Rq user=mailfilter argv=/home/mailfilter/spam-filter ${user} -f ${sender} -- ${recipient} This ensures that both the original sender and recipient information is available to the filtering script. The script should be something like: ,----[ spam-filter ] | #!/bin/busybox sh | user="$1"; shift | exec spamc -u "${user}" | /usr/sbin/sendmail -i $@ `---- Using a statically linked busybox shell produced something close to an order of magnitude improvement in performance when it came to filtering massive volumes of email, FWIW, both through small size and through the lack of dynamic linking and seeking required. The important part, though, is piping the email back to sendmail with the -f switch specified. This ensures that the information on the original sender is identical. That /should/ give you the results you want, together with an improvement in performance. If you *really* need to file off the content into a distinct mailbox you can obviously use temporary files or other tricks to modify actions based on the result of the spamc run. Fundamentally you would want this to change the recipient of the mail, though, not deliver locally from this script. That should fix your problem, though I can't promise anything as I don't /know/ that this is the problem with Exchange, just suspect it. It sounds exactly like the sort of thing that Exchange loves to do, though, and matches my expectations of your setup the whole way through. Daniel -- Life in Lubbock, Texas taught me two things. One is that God loves you and you're going to burn in hell. The other is that sex is the most awful, dirty thing on the face of the earth and you should save it for someone you love. -- Butch Hancock _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
