[Mimedefang] Multiplexor trouble

[Steffen Kaiser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

my problem has probably happen before to someone else: 
http://lists.roaringpenguin.com/pipermail/mimedefang/2002-March/009506.html

If the error would tempfail the message, well, it's low volume; but the 
most problem is that the milter returns results of different queries to 
the sendmail process:

sm-mta-ext[31396]: o9FB1Ls1031396: Milter: to=<[existant-internal-user]>, 
reject=550 5.1.1 <[non-existant-one]>: SMTP VRFY: 550 5.1.1 
<[non-existant-one]>... User unknown

The error description is generated by my filter_recipient() lookahead 
test, that the addresses of "to=" and the description differ means that 
sendmail got the result of _another_ _query_ from the Milter, because the 
address in the error description is the address tested! I can also verify 
this by the log entries of the MIMEDefang filter, because the 
[non-existant-one] mail address has been checked only once in the last 
week and this had been an external mail, whereas the failed message was an 
internal one, _and_ that pariticular message immediately preceeds message 
o9FB1Ls1031396 in the logs.

In the above mentioned thread there is the reply "Do you run two 
multiplexors?" My system consists of two identical sendmail-MIMEDefang 
instances, in order to reserve a certain number of slots for internal 
communication. Each sendmail instance has its own socket with multiplexor 
/ mimedefang chain. Messages from external sources are remapped to another 
port by the firewall, the internal communication uses the standard 25 & 
587 ports. This setup runs for years now. I use MIMEDefang v2.64 on 
sendmail 8.13.8-3 / Linux Etch.
(I know both are old, but I do not see anything in MIMEDefang's Changelog, 
which effect may problem, maybe: v2.68-BETA4 "* Fix a really stupid 
segmentation fault when handling multilinereplies.")

To reload the filter did not changed anything.
A restart of the MIMEDefang stuff helped for some time only.
I now did a reboot of the whole machine and did not see the problem again 
for about 1.5days.
I do see the possibility that the reboot did not helped, but that the 
problematic message simply did not returned since then.
I also do see the possibility that I have bad hardware, e.g. a RAM failure 
or so.

===

Howerever:
I'm reminded of the problem with the socket map implementation: 
http://lists.roaringpenguin.com/pipermail/mimedefang/2007-June/032936.html 
esp. I wonder about the first line in the logs below. Can the buffer limit 
hit in different situations as well? This line looks like a part of 
another one, as described in the post.

I've seen the following entries in the log, before this first line, there 
are only errors "no response from slave":

Oct 15 00:10:47 ux-2s14 mimedefang[27529]: Error from multiplexor: 
.10.2010%2021:XX:%20IP%2087.230.54.44%20with%20name%20d [cut]
Oct 15 00:19:27 ux-2s14 mimedefang[27529]: Error from multiplexor: ok 1 ok 
250 2.1.0 0
Oct 15 01:20:51 ux-2s14 mimedefang[27529]: Error from multiplexor: 
10.2010%2020:XX:%20IP%2087.230.54.44%20with%20name%20ds87-230-54-44. [cut]

Oct 15 03:04:13 ux-2s14 mimedefang[27529]: Error from multiplexor: ok 1 ok 
250 2.1.0 0
Oct 15 03:04:23 ux-2s14 mimedefang[27529]: Error from multiplexor: error: 
o9F14CPl015650: Cannot mkdir(Work): No such file or directory
Oct 15 03:05:49 ux-2s14 mimedefang[27529]: Error from multiplexor: ok 1 ok 
250 2.1.0 0

Oct 15 03:22:00 ux-2s14 mimedefang[27529]: Error from multiplexor: error: 
o9F1L5Vj016810: couldn't open INPUTMSG: No such file or directory
ct 15 10:45:45 ux-2s14 mimedefang[27529]: Error from multiplexor: error: 
Cannot chdir(/var/spool/MIMEDefang/mdefang-o9F8jCIw017949): No such file 
or

There are corresponding errors from mimedefang.pl processes, which process 
IDs never overlap, meaning, they change over time, but are never 
interleaved.

Regards,

- -- 
Steffen Kaiser
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iQEVAwUBTL1UDUgddVksjRnHAQKUfAf+MUps99Xr0wmF1TH1bWf8iZcHXZ0wec02
moYhUPD8xF1Zg2/oP9qwYYF3/Jl468IoBxZEDJJkRiJVURfRCtR2kuUJ0F1Sl4i/
v6TzNL1KIaOW/POs8/8kygNRURpk0cW5lZiDgjVk0TzTSYUkCsOE3p6gP+2hr1xe
pvOCfwFTZqEq/qYV/8NFbfQx5Iq7ukKd/pWgEH+IFtVBzjU+ETmguOzHeqjgS2Zu
btfLukE7bDjOqoMjzikM8+wBZLD5s5FnYy3eZtWjAb4t4uWy+MeUM7G98jfupb2j
V1H/WQXKJrhV4Wp9X0uylXzkNUvlSzz1LxXyaiaWs+nfY78IWzOdGA==
=tjLg
-----END PGP SIGNATURE-----