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

[Glenn Steen]

On 16/01/07, Nerijus Baliunas <nerijus at users.sourceforge.net> wrote:
> Glenn Steen <glenn.steen <at> gmail.com> writes:
>
> > Currently this only seem to affect milters, and only milters that
> > would add recipients and/or message headers.
>
> First, thank you very much for looking at this problem!
> I commented out all lines with smfi_addheader() and changed xxfi_flags field
> from SMFIF_ADDHDRS to 0 in milter-greylist, which means it does not modify
> headers or body. But I still get "              0" after the end of body and "
>             0" too after the last header (instead of "           1389" earlier).
> Does it mean Postfix changes queue files when milters are enabled even when
> milter does not announce the capability of changing the message?

Yes! Thank you Nerijus for corroborating this in RL:-).
What the code implied (abnd what code implies usually _is_ how it
works, but... there is a frail human intellect that is to interprete
code so....:-) is that when milter is used postfix prepares the queue
files for inline editing by adding three p records that essentially
say "jump to position 0" which is interpreted as "ignore me". So
unless we fix MailScanner, milters are offlimits with postfix.
We can't have that, and I will be making a stab at ...
"de-p-recordizing" the queue file we produce. Workload willing,
perhaps we'll see something today. Unfortunately Jules will be unable
to help much, due to health and workload... But anything I produce
will be going through him (and you  all:) for code review... I'm not
the programmer I used to be, so it'll be needed:-):-).

According to a private conversation with Jules, this will likely not
make it into the next stable release though (we need test whatever we
can cobble together thoroughly).

> > Now, I see at least three somewhat different solutions:
> > 1) Simply enhance the ReadQf function so that it understands and
> > handles p records (meaning we will copy over the actual data added by
> > milters, not the p records themselves).
> > 2) recalculate the offsets and make sure the precords ar correct, as
> > well as the "after end" data being where it is supposed to be.
> > 3) Rewrite MailScanner to use the same p record method of adding
> > recipients and headers, which of course implies, in a way, that we
> > would reimplement the Postfix.pm file from scratch... more or less.
>
> It would be quite nice, meaning MS is changing queue files in official way(?),
> but it would also mean MS will not support postfix versions below 2.3, when
> milter support was added.
Well not really "official", no:-). The postfix devels don't want us
touching the queue files at all.
We're going to aim at #1 for now. It will ensure compatibility with
all current stable versions. And hopefully we'll be ablöe to handle
body edits in a sane manner when it arrives (2.4, it seems).

> > I'm hugely in favour of doing number 1), since this will be
> > a) simplest to implement
> > b) least amount of code touched
> > c) probably safest... We'll have to look at doing pretty much the same
> > sanity checks that Wietse does, but that shouldn't be a huge problem.
>
> Yes, it's probably the best approach.
>
> > If I get a little teensy bit of time, I'll make a stab at some code
> > for handling p records as suggested in #1.
>
> Thanks!
>
> BTW, I've got an idea about how to temporary overcome the problem with
> corrupting headers. Is Postfix able to add some headers to the message? If yes,
> I would configure it to add some header, then pass message to a milter, milter
> adds "              0" after this header corrupting it, but it means all the
> other important headers are left intact (like Content-Transfer-Encoding:
> base64). So is this possible?

Not sure. Might be worth a try:).
But I need concentrate on the #1 solution, for now:P
> Regards,
> Nerijus
>

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