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.
>>>
>>
>
>