Milter-greylist

On 2013-08-13 14:34, Emmanuel Dreyfus wrote:
> On Tue, Aug 13, 2013 at 01:52:44PM +0200, Jim Klimov wrote:
>> So there a couple of things to do:
>> 1) revise that domain/username format substrings do not crash with
>> empty input;
>> 2) understand why the recipient is empty in this context?..
>
> Does that mean milter-greylist-4.4.3-p0f-noCrash.patch is not
> finalized yet?

No, that is a different crash in a different location for different
reasons. Unlike p0f, it left no clues in the log, so it is my guess
from experimentation (trying different addheader strings) that the
culprit is with an empty '%r' in this context, and so on as detailed
in that letter.

> On Tue, Aug 13, 2013 at 12:07:33PM +0200, Jim Klimov wrote:
>> The main question is: if the "local address" is wrong in p0f.c:380,
>> should we really abort the whole program, or just not do further p0f
>> processing?
>
> Please send code snippet? I do not see what part you talk about.

I believe that since you have already seen and/or reviewed the
milter-greylist-4.4.3-p0f-noCrash.patch, you don't need that
snippet (it is the default case, where I changed exit to return).

>
>> Aug 13 10:07:05 ucs milter-greylist: [ID 447650 mail.error] unexpected AF
>
> milter-greylist was built without Ipv6 support?

I think not, should have IPv6. It just seems to happen that for
the Messaging Server's queue reprocessing, there is no address
set at all, since this is not happening in the context of a live
SMTP dialog. Maybe this is a bug on their behalf, but unlikely
to change soon anyway.

In general, maybe localaddr should have been used here too as a
fallback in a situation like this, but at least for p0f - an MTA's
offline reprocessing stage is anyway too late to try any (passive)
IP fingerprinting of the remote original host.

//Jim Klimov