On Saturday 15 December 2007 13:28:22 Jukka Salmi wrote:
> While dkim-milter responded to this particular SMTP session within a
> second, I just noticed that each time this problem happens (i.e.
> dkim-milter fails with `"X-DKIM" header add failed'), there are two
> additional open connections from other MTAs which are not yet handled
> by dkim-milter - they both time out after dkim-milter fails:

Interesting association of events. Does your dkim-filter run
with auto-starting option - or better, is the PID as reported
by dkim-milter after these event (on a next normal session)
the same as before the event?

> However, as Tony wrote, this probably belongs to the Postfix ML...

I'm not so sure. Until you capture and analyze a failing milter
session you won't know whether the problem report should be
directed to postfix or to dkim-milter, or maybe even to the
OS or its sockets layer.

> I'm using unix domain sockets - AFAIK it's not possible to
> capture a session in this case, is it?

I don't think that is possible. This is why I'd suggest you
switch to inet socket on a loopback interface. All you need
to do is to change the socket specification on a MTA side
and on a command line to a dkim-filter. Something like
-p inet:[EMAIL PROTECTED] on a dkim-filter, and a
smtpd_milters=inet:127.0.0.1:4444 on the Postfix side.
This also does away with a tricks you need to play with
Unix socket ownership and protection to make it work.

  Mark


-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
dkim-milter-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dkim-milter-discuss

Reply via email to