milters with postfix
Glenn Steen
glenn.steen at gmail.com
Tue Jun 26 17:02:52 IST 2007
On 22/06/07, Glenn Steen <glenn.steen at gmail.com> wrote:
> On 22/06/07, Glenn Steen <glenn.steen at gmail.com> wrote:
> > Get me a sample. . . T9 playing tricks on me:)
> >
> > On 22/06/07, Glenn Steen <glenn.steen at gmail.com> wrote:
> > > Could you get of a sample queue file? Both before and after?
> > >
> > > On 22/06/07, Nerijus Baliunas <nerijusb at dtiltas.lt> wrote:
> > > > Hello,
> > > >
> > > > I updated to postfix 2.4.3 and mailscanner 4.61.3 and the old problem
> > > > with corrupted headers is back again. But the " 0" is added not after
> > > > the last header as before, but in the middle of the headers:
> > > >
> > > > From: Nerijus Baliunas <xxx at example.lt>
> > > > Subject: 2
> > > > 0
> > > > To: postmaster at example.lt
> > > >
> > > > Any ideas? Should I provide email samples and queue files again?
> > > >
> > > > Regards,
> > > > Nerijus
>
> Well, thanks to Nerijus, who sent a comprehensive set of queue files
> and the corresponding (mangled) results, I now see that something (in
> MailScanner) has botched the w (deleted) record in the problem case
> ...
> When I find them in the body, I simply ignore them, but in the header
> section(s) I fall back on Jules sane thing of simply copying them over
> as is ... This seems to be less than working though, so I'll either do
> a patch (next week) to simply skip them in the header(s) too, or try
> make sure they don't get mangled (if I can find out why).
> The first method is quite sane, since we really don't need them... And
> it just might be that we should (contraintuitively) do the
> "reintroduction of an empty p record" I talked about a while back, if
> postfix itself relies on the occurrence of p records to correctly
> handle w records (I haven't checked the PF code for this... Just might
> be something like that happening... Sigh).
> When I do something about this, I'll do the fix for Fred Stein too, to
> only do the body spin-through in ReadQf for queue files containing p
> records... Thinking like Linus.... "Don't sacrifice the common case
> performance for the odd case":-).
>
> Since I'm off celebrating a traditional midsummer's eve (with all that
> entails (see how restrained I am, Hugo:-)) I wouldn't trust any code
> leaving my fingers ... So it'll have to be sometime Monday or Tuesday
> ... at the earliest:-)
>
> BTW Jules, when you feel a bit better you really should come sample
> the pickled herring ... and ... assorted attributes...:-). Would be a
> shame if the world tour was on hold indefinitely;-)
>
> Cheers
As promised, here's a patch to handle two of the things mentioned above:
1. ignore w record (stands for "deleted") if found in the header
section of the body. It turns out that Jules actually treat all
headers like N (for normal) records, so add that in later (not
preserving the "p" or "w"), so we need do this... Just like in the
body. The other place where p/w records can crop up is handled by
copying the records over verbatim, just as before. I first thought
this had to do with handling the Subject: (and Recieved:) headers
specially, but realised it was a more common thing. Anyway, the fix is
a one-liner.
2. Speedup for the normal, non-milter, case. If we haven't found any p
records, skip the sometimes lengthy (depending on body size) spin
through that we need when doing milters. Thus the normal case will
become very close, in processing time, to how it was before the p
record handling was introduced. This is actually a whooping 4 line
thing:-).
The thought about reintroducing "zero p records", to keep the queue
files "ready for milters when locally resubmitted via semi-non-manual
methods", will have to wait until another time. If ever.
I don't envision that to be a big need, since you will either resubmit
directly to the incoming queue (way after any "local milters"), or
you'll likely not use any local milters at all (... someone will prove
me wrong here, I'm sure:-).
Anyway, I'm seriously swamped at work (colleagues dropping kids left,
right and center... going of on paternity leave and vacation and
whatnot. Sigh. Well, in a few days I'll go on vacation too:-), so that
will just have to wait until I have the time to test that thoroughly
(the changes should be minimal, but I have to get a handle on just
_where_ to put the reintroduced "empty" p record, so that it doesn't
get transformed into a N record, or somesuch:-)
Jules (& everybody:-), I would be very glad if a few could test this
out rather soon, and if there (pretty please) could be a beta with
this in it... So that it can make it into the next stable release.
Cheers
--
-- Glenn
email: glenn < dot > steen < at > gmail < dot > com
work: glenn < dot > steen < at > ap1 < dot > se
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Postfix.pm.prec_wrec_speedup.patch
Type: application/octet-stream
Size: 2569 bytes
Desc: not available
Url : http://lists.mailscanner.info/pipermail/mailscanner/attachments/20070626/15e4619a/Postfix.pm.prec_wrec_speedup-0001.obj
More information about the MailScanner
mailing list