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

[Glenn Steen]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Postfix.pm.prec.patch
Type: text/x-patch
Size: 5639 bytes
Desc: not available
Url : http://lists.mailscanner.info/pipermail/mailscanner/attachments/20070116/06b472f7/Postfix.pm.prec.bin