Jeff Weinberger a écrit : > On Jan 2, 2009, at 9:20 AM, mouss wrote: > >> Jeff Weinberger a écrit : >>> >>> It's definitely my set up. I don't use LMTP to pass the message to >>> dspam, I use a transport called "dspam" that uses pipe. That means >>> there's no S/LMTP dialog, just the message itself passed as STDIN. >>> >> >> so _you_ are not passing the envelope sender to dspam. >> >> Consider running dspam in "relay mode": >> postfix --(LMTP)--> dspam --(SMTP)--> postfix >> >>> I have to move dspam to use LMTP and then move it to a before-queue >> >> why do you want to run it in pre-queue mode? This is not needed and is >> not simple to setup. >
Is there a reason why you keep adding yahoo groups after I remove them fro CC? This is starting to annoy me... and by the way, disable the X-DSPAM-Factors header. dspam doesn't encode it, which results in things like: X-DSPAM-Factors: 27, ... a+écrit, 0.01000, and this is not a valid header. > If I understand your diagram, then the content_filter would look like: > > content_filter=lmtp:unix:/path/to/dspam args No. content_filter=lmtp:inet:127.0.0.1:10024 where the 10024 is the same port used in dspam.conf: ServerPort 10024 of course, dspam must be running in daemon mode. > > and that might pass through the envelope information (I'm not convinced, > but if dspam can do it, that would be how). LMTP is similar to SMTP, and dspam can run as an LMTP server (this is configured in dspam.conf). > > But since dspam can speak LMTP and SMTP dspam has a server and a client. so which speaks what? if we are talking about the server part: $ cd dspam-3.8.0/src $ cat daemon.c ... input = daemon_expect(TTX, "LHLO"); if (input == NULL) goto CLOSE; ... it wants LHLO (which is for LMTP), not HELO or EHLO. so no smtp there. > why would an smtpd proxy be hard > to set up? It would certainly avoid the bcc issues, etc. I don't understand why you mix pre-queue and bcc. maybe you confuse pre-queue with a "not simple content filter"? > that I" > experiences by having the message run through postfix twice. After > reading through SMTPD_PROXY_README, it seems like a bit of a challenge > to make it work, but not that hard...what do you think might be difficult? > > Thanks for all your help - over the course of thi dialog I've learned a > lot about postfix and have become more aware of and proficient with > parts I knew little about. This has been very helpful. > >> >> >>> content filter so that this workaround becomes unnecessary, but until I >>> go to make those changes, this will suffice. >>> >>> I'm not completely convinced that dspam will work seamlessly as a >>> before-queue content filter, so I'll have to do some testing to see how >>> well that works and whether it can do what I need and hand fully formed >>> messages with SMTP dialog information back to postfix. >>> >> > >