{Disarmed} Re: {Disarmed} Re: Problems with 5.1.1 milter

Fri Oct 12 06:40:49 UTC 2018

The origin was local. I see a copy delivered to me in the maillog, but I don't
see any delivery to the remote recipient.

On Thu, 11 Oct 2018 09:15:10 -0400 Shawn Iverson via MailScanner <mailscanner at lists.mailscanner.info> wrote:

> If the other user was remote, and the origin of the email was remote, then
> that problem is between the origin MTA and the remote MTA and not your
> MTA.  Your system is not responsible for delivering a copy of an email for
> a remote entity.  In fact, this would mean you would be an open relay
> forwarding mail for others, which is bad.
> 
> On Thu, Oct 11, 2018 at 9:12 AM Nerijus Baliunas <
> nerijus at users.sourceforge.net> wrote:
> 
> > On Thu, 11 Oct 2018 07:48:27 -0400 Shawn Iverson via MailScanner <
> > mailscanner at lists.mailscanner.info> wrote:
> >
> > > That message means the mail was queued to mailscanner.  Were both
> > > recepients in the same email?
> >
> > Yes.
> >
> > >  Were both recipients in the same domain?
> >
> > No. I was local, and I got the message, remote recipient did not.
> >
> > > On Thu, Oct 11, 2018, 5:43 AM Nerijus Baliunas <
> > > nerijus at users.sourceforge.net> wrote:
> > >
> > > > Hello,
> > > >
> > > > I had a few such messages in maillog:
> > > >
> > > > Oct 10 11:06:20 bluegene postfix/cleanup[2519]: 8AED1181849997:
> > > > milter-discard: END-OF-MESSAGE from ip3 [192.168.0.3]: milter triggers
> > > > DISCARD action; from=<g at example.com> to=<other at example.com>
> > proto=ESMTP
> > > > helo=<g.example.com>
> > > >
> > > > The message was sent to me and one other email address. I got it, but
> > > > other didn't,
> > > > and I don't see anything more in logs, so it seems the message was
> > lost.
> > > > Is is related to this issue?
> > > >
> > > > Regards,
> > > > Nerijus
> > > >
> > > > On Sun, 7 Oct 2018 15:36:02 -0400 Shawn Iverson via MailScanner <
> > > > mailscanner at lists.mailscanner.info> wrote:
> > > >
> > > > > Mark,
> > > > >
> > > > > There's a performance fix in this commit that should help with most
> > of
> > > > > this.  The crashing is likely from partially written messages in the
> > > > > milterin queue as a result of not writing the file in a single
> > pass.  I
> > > > > hope to get a few more issues resolved before doing another release.
> > > > >
> > > > >
> > > >
> > https://github.com/MailScanner/v5/commit/5083b4e0f0eecbec84a5ab94538b0ffbe35f90f1
> > > > >
> > > > >
> > > > >
> > > > > On Sun, Oct 7, 2018 at 2:17 PM Mark Sapiro <mark at msapiro.net> wrote:
> > > > >
> > > > > > This is basically just a report of things I encountered with the
> > milter
> > > > > > option in MailScanner 5.1.1. I don't think I have enough
> > information to
> > > > > > actually debug these issues, and for now at least, I have reverted
> > to
> > > > > > the Postfix hold queue option.
> > > > > >
> > > > > > I first set up the milter option on a local test server. Mail
> > wasn't
> > > > > > being scanned, but this was because I was submitting the test mail
> > from
> > > > > > localhost. When I submitted mail remotely, all seemed to work
> > well, so
> > > > I
> > > > > > then set up the milter option on my not too busy production
> > server. I
> > > > > > set it up at about 9:30 p.m. on Friday. It seemed to be working
> > well.
> > > > > >
> > > > > > At some point Saturday, I noticed some delays so I began to
> > > > investigate.
> > > > > >
> > > > > > I saw this in mail.log
> > > > > >
> > > > > > Oct  6 08:35:50 sbh16 MailScanner[3301]: Requeue: 2BA30E13AF.AAFEC
> > to
> > > > > > DB2E81180AC8
> > > > > > Oct  6 08:35:50 sbh16 postfix/smtpd[6686]: connect from
> > > > > > localhost.localdomain[127.0.0.1]
> > > > > > Oct  6 08:36:20 sbh16 postfix/smtpd[6686]: warning: milter
> > > > > > inet:127.0.0.1:33333: can't read SMFIC_OPTNEG reply packet header:
> > > > > > Connection timed out
> > > > > > Oct  6 08:36:20 sbh16 postfix/smtpd[6686]: warning: milter
> > > > > > inet:127.0.0.1:33333: read error in initial handshake
> > > > > >
> > > > > > This seemed to be a one time occurrence. Mail was processed
> > normally
> > > > until
> > > > > >
> > > > > > Oct  6 11:16:39 sbh16 MailScanner[7312]: Requeue: B679E47A37.A9D7F
> > to
> > > > > > A7D441181110
> > > > > > Oct  6 11:16:39 sbh16 postfix/smtpd[27861]: connect from
> > > > > > localhost.localdomain[127.0.0.1]
> > > > > > ...
> > > > > > Oct  6 11:17:09 sbh16 postfix/smtpd[27861]: warning: milter
> > > > > > inet:127.0.0.1:33333: can't read SMFIC_OPTNEG reply packet header:
> > > > > > Connection timed out
> > > > > > Oct  6 11:17:09 sbh16 postfix/smtpd[27861]: warning: milter
> > > > > > inet:127.0.0.1:33333: read error in initial handshake
> > > > > > ...
> > > > > > Oct  6 11:17:10 sbh16 postfix/smtpd[27861]: connect from
> > > > > > unknown[185.36.81.145]
> > > > > > Oct  6 11:17:40 sbh16 postfix/smtpd[27861]: warning: milter
> > > > > > inet:127.0.0.1:33333: can't read SMFIC_OPTNEG reply packet header:
> > > > > > Connection timed out
> > > > > > Oct  6 11:17:40 sbh16 postfix/smtpd[27861]: warning: milter
> > > > > > inet:127.0.0.1:33333: read error in initial handshake
> > > > > >
> > > > > > at which point these seemed to occur with every connect even though
> > > > > > 'netstat -lntp' showed the milter listening on port
> > > > > >
> > > > > > About an hour later, I reverted to the non-milter configuration and
> > > > > > things became normal again.
> > > > > >
> > > > > > Also during the 14 hours that the milter was configured, I saw 4 of
> > > > these
> > > > > >
> > > > > > Oct  5 22:58:44 sbh16 MailScanner[7746]: Quarantined message ...
> > as it
> > > > > > caused MailScanner to crash several times
> > > > > >
> > > > > > I have those 4 messages and have reprocessed them following
> > reversion
> > > > to
> > > > > > the hold queue method with no problem. I also processed them
> > through my
> > > > > > test server running the milter without crashing MailScanner. On the
> > > > test
> > > > > > server, I did see
> > > > > >
> > > > > > Oct  6 15:21:39 msapiro MailScanner[13351]: Unable to kick message
> > > > > > /var/spool/MailScanner/milterout/5ECA5340128, will retry soon...
> > > > > >
> > > > > > on 3 of the four messages which remained in milterout, but this may
> > > > have
> > > > > > been related to the fact that I submitted all 4 in one manual smtp
> > > > > > session and then never submitted any more messages before reverting
> > > > that
> > > > > > to the hold queue method.
> > > > > >
> > > > > > So, I don't think that the "caused MailScanner to crash" issue was
> > > > > > related to the actual message content.
> > > > > >
> > > > > > My milter config overrides defaults with
> > > > > >
> > > > > > ---------------------------------
> > > > > > Incoming Queue Dir = /var/spool/MailScanner/milterin
> > > > > > Outgoing Queue Dir = /var/spool/MailScanner/milterout
> > > > > > MTA = msmail
> > > > > > MSMail Queue Type = short
> > > > > > Milter Scanner = yes
> > > > > > Milter Max Children = 1
> > > > > > ---------------------------------
> > > > > >
> > > > > > I wonder if people are successfully using this in production or if
> > > > > > people have seen issues such as this?
> > > > > >
> > > > > > --
> > > > > > Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
> > > > > > San Francisco Bay Area, California    better use your sense - B.
> > Dylan
> > > > > >
> > > > > >
> > > > > > --
> > > > > > MailScanner mailing list
> > > > > > mailscanner at lists.mailscanner.info
> > > > > > http://lists.mailscanner.info/mailman/listinfo/mailscanner
> > > >
> > > >
> > > >
> > > > --
> > > > MailScanner mailing list
> > > > mailscanner at lists.mailscanner.info
> > > > http://lists.mailscanner.info/mailman/listinfo/mailscanner
> >
> >
> >
> > --
> > MailScanner mailing list
> > mailscanner at lists.mailscanner.info
> > http://lists.mailscanner.info/mailman/listinfo/mailscanner