Erik Logtenberg:
> Hi,
>
> I wrote a small milter using Sendmail::Milter in perl. This worked okay
> with postfix 2.6.5, but it doesn't with 2.7.0. I use the i-macro
> (postfix queue-id) in the EOM-callback function. Previously, the i-macro
> was always set at this stage, but now this is no longer the case. I
> built the milter to tempfail on a missing i-macro, so that is what
> happens now.
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
