Greylisting (WAS: Re: MailScanner ANNOUNCE: 4.57 released)

[Glenn Steen]

Sorry for the top post all, I'll try to be brief.

The below (and the patch) was just a tad (:-) naïve on my part. After
reading up on the 2.3.6 and latest 2.4 snapshot code of postfix, I now
know (thanks in great part to a very informative and longish comment
by Wietse in cleanup_milter.c) that some of the assumptions were...
less than correct. For one thing, we need preserve w records (deleted
data) in the body as well as in the header segment. For another, there
might be p records in any position that has been edited (/replaced) or
inserted, and the dummy records are there so that the segmenty end
markers (M, X and E records) won't be moved. ... And multiple "same
record type" edits will lead to multiple forward p records to the one
backward p record. Sigh.
I still think we should do something like this first draft, just
enhance it a bit to take the above into account:-).

Oh well, more to come in a few days:-)

Cheers
-- Glenn

On 16/01/07, Glenn Steen <glenn.steen at gmail.com> wrote:
> Tuesdays aren't any better, it seems ... look below.
>
> On 15/01/07, Glenn Steen <glenn.steen at gmail.com> wrote:
> > It really is monday today, isn't it:-)...
> >
> > On 15/01/07, Glenn Steen <glenn.steen at gmail.com> wrote:
> > (snip)
> > > Well, after reading some code I at least know what is going on, and
> > > why it doesn't work:-).
> > >
> > > Wietse seems to have wanted a way to ... noninvasively... insert
> > > additional data into the Postfix queue file without having to rewrite
> > > the whole thing (as we more or less do in MailScanner), so that
> > > milters could just "tag on" new recipients and headers.
> > >
> > > To that effect he made it so that there might be two (or more? I'm not
> > > really clear on this yet, but iut seems there will only be one p
> > > record for additional recipients, but perhaps one per added header)
> > > records of type "p" (for pointer) that has a "value part" of 0 by
> > > default, meaning no "extra info" is to be inserted at that point. If
> > > there is a non-zero value, this is an absolute offset to fseek to for
> > > the actual inserted part, followed by another p record with an
> > > absolute offset to jump back up into the file to the original "jumpoff
> > > point" (after the original p record). The added records are tagged on
> > > after the end record (and a null character denoting end of file?). As
> > > one can guess, much of Wietses patches regarding milter support seem
> > > to focus on detecting and handling missbehaving subsystems that create
> > > p record message loops (wrong "jump-back offsets" leading to endless
> > > loops ("here we GOTO again!":-)).
> >
> > This description is slightly wrong. Looking again, one can see that
> > the p records ("jumpoff points", or branches, if you like:-) can be
> > located at three different places in the queue file:
> > 1) just after the first set of O and R records (before the M record),
> > 2) just after the headers in the M record, but before the body (before
> > the empty N record)
> > 3) at the same place we place our modifications... after the body,
> > before X and E (Not at work, might remember this wrong...might be just
> > before the E, but I think it's the same place where we add things.
> > This hit me when idly thinking about work on the train home... That
> > is, almost nodding off on the train home:-)
>
> Damn, I'm stupid. No way around it, the thing was glaring me in the
> eyes. Oh well.
> I've now completed the first rough edit of Postfix.pm to handle the
> first two (as I thought, three) p record removal thingies (first is
> recipients, second is headers ...). Seems to work niocely with my
> tests.
> But then the third one (which in my tests always is a 0 p record and
> should just be removed) plain stuck, hanging around after MS is done.
> Bummer.
> Then it it me: The third one isnät for recipients or post message
> attribute editing... It's for body edits (well, additions:-). So I'll
> have to find some time to do something about PFDiskStore.pm as well.
> Oh well.
> I should be able to make some assumptions about that, probably making
> some fairly simple changes. Worst case I'll have to meddle a bit with
> the Body class.
> We'll see where we land:-).
> I've attached a diff for Postfix.pm, it is very rough (little error
> handling... Where I detect an error, I think I should just set
> $ErrorFound, move to a sane file position and let it flow down to the
> resulting (error) return, right Jules?) and the last chunk (that is
> pertaining to the post message record handling) is probably not needed
> at all (since I was looking at it a bit wrong).
>
> PFDiskStore.pm to come (for the body bit:-)...
>
> Cheers
> --
> -- Glenn
> email: glenn < dot > steen < at > gmail < dot > com
> work: glenn < dot > steen < at > ap1 < dot > se
>
>
>


-- 
-- Glenn
email: glenn < dot > steen < at > gmail < dot > com
work: glenn < dot > steen < at > ap1 < dot > se