Thank you Wietse,
I tested with test-milter per your instructions and confirmed that
postfix does indeed include the i-macro. After some more digging I found
out that Fedora installed Sendmail::PMilter instead of the apparently
obsoleted Sendmail::Milter package. Unfortunately for some reason
PMilter understands all macros except i (?) I have no clue why...
Anyway, I reverted back to Sendmail::Milter and all is well again.
Thank you again for your useful pointers on debugging this issue!
Kind regards,
Erik.
On 08/22/2010 11:34 PM, Wietse Venema wrote:
> As with Postfix 2.3, Postfix sends the I macro by default, as
> observed with the test Milter program (test-milter.c, included with
> Postfix source code):
>
> test_eom
> macro: i="972E0547B07"
> macro: j="tail.porcupine.org"
> macro: v="Postfix 2.8-20100728"
> macro: {daemon_name}="tail.porcupine.org"
> macro: {mail_addr}="wie...@porcupine.org"
> macro: {rcpt_addr}="wie...@porcupine.org"
> test_reply 0
>
> Also visible with verbose logging from the cleanup server:
>
> Aug 22 17:11:34 tail postfix/cleanup[7980]: event: SMFIC_BODYEOB; macros:
> i=972E0547B07
>
> Finally, tcpdump will also capture the info but requires manual
> disassembly of the data stream:
>
> IP_HDR=20 IP_OPT=0 TCP_HDR=20 TCP_OPT=12 DATA=25 FLAGS=PUSH ACK
>
> IP_HDR 45 00 00 4d 0b af 40 00 40 06
> vhl tos len len id id off off ttl pro
> IP_HDR 00 00 7f 00 00 01 7f 00 00 01
> sum sum src src src src dst dst dst dst
> TCP_HDR 8a 4d 27 0f cb f3 9f e4 b4 fd
> src src dst dst seq seq seq seq ack ack
> TCP_HDR ca 3c 80 18 23 00 7d e8 00 00
> ack ack off flg win win sum sum urp urp
> TCP_OPT 01 01 08 0a 03 7a 94 35 9e 5c
> opt opt opt opt opt opt opt opt opt opt
> TCP_OPT c9 c5
> opt opt
> DATA 00 00 00 10 44 45 69 00 39 37
> ^@ ^@ ^@ ^P D E i ^@ 9 7 ....DEi.97
> DATA 32 45 30 35 34 37 42 30 37 00
> 2 E 0 5 4 7 B 0 7 ^@ 2E0547B07.
> DATA 00 00 00 01 45
> ^@ ^@ ^@ ^A E ....E
>
> 00 00 00 10 is a packet length (16 bytes)
> 'D' means that the packet contains macros
> 'E' means that these are end-of-body macros (SMFIC_BODYEOB)
> 'i' is the name of the macro terminated by null byte
> 972E0547B07 is the value of the 'i' macro terminated by null byte
>
> 00 00 00 01 is a packet length (1 byte)
> 'E' means end of body (SMFIC_BODYEOB).
>
> The constants are defined in the Postfix source, and in
> /usr/include/libmilter/mfdef.h
>
> Without even understanding anything about the Milter protocol you
> should be able to find this. The next TCP packets are a reply from
> the Milter containing one byte with 'c' meaning "continue", and a
> command from Postfix containing one byte with 'Q' which means
> "quit".
>
> It is possible that the Milter requests that Postfix does not notify
> it about certain events that it is not interested in; in that case
> Postfix won't report those events (and their milter_xxx_macros) to
> the Milter application.
>
> To debug, it's probably easiest to hook in the Postfix test-milter
> program first to convince yourself that Postfix sends 'i' at EOM
> time.
>
> # postconf -e {,non_}smtpd_milters=inet:127.0.0.1:9999
> # postfix reload
>
> $ ./test-milter -d 2 -p inet:9...@localhost
>
> Then send some test message.
>
> To debug the flow with the perl application, you may need to
> capture a tcpdump recording.
>
> Wietse
