On Feb 25, 2014, at 7:35 PM, Noel Jones wrote:

> On 2/25/2014 6:06 PM, CSS wrote:
>> 
>> On Feb 25, 2014, at 9:50 AM, Noel Jones wrote:
>> 
>>> On 2/25/2014 4:44 AM, Eivind Olsen wrote:
>>>> Hello (or should that be EHLO? :))
>>>> 
>>>> It has been a while since I've had a need to change my Postfix
>>>> configuration, so I'm a bit rusty. I have searched, checked the
>>>> configuration, etc. No luck yet.
>>>> 
>>>> Is it possible to get Postfix to log the hostname presented to it during
>>>> HELO/EHLO? Any configuration setting I've missed? Or will I have to change
>>>> the sourcecode for this?
>>> 
>>> 
>>> If you don't want to patch the source, an easy workaround is to add
>>> to your header_checks file:
>>> /^From: / WARN
>>> which will log some information including the helo. This works with
>>> any version of postfix.
>>> 
>>> 
>>> 
>>> If you don't mind a little patch, here's a simple patch I've used
>>> for years to log the HELO hostname. This will apply to postfix 2.8
>>> and newer.
>> 
>> That is so qmail-esque (in a good way, seriously).  I really like
>> the idea of logging the helo from a data analysis perspective.
>> 
>> I wonder if you could do this with a simple policy server?  IIRC,
>> the helo is one of the bits of data passed to the policy server, and
>> logging the IP, to/from, helo and a few other things seems like it
>> would be pretty simple.  And just return an OK.  Of course it would
>> be a totally separate log file, but you'd have the data and you
>> wouldn't have to alter the postfix source.
> 
> Yes, that's possible.  Make sure your policy service always returns
> DUNNO, not OK, to postfix.  But having a separate log seems messy.

Just to make sure I understand this, DUNNO is going to let any
further policy checks happen, OK would stop the match and any
further checks would not happen (which would be bad), correct?
Bear with me, I've skated along with minimal knowledge of Postfix
for years and have just started ingesting the docs on the policy
stuff…

I don't think I'd personally implement such a thing, although I am
now thinking it might be nifty to try my hand at a simple statistics
gathering policy server as a little exercise in putting such a thing
together.  I know you can grab lots of information with various log
analysis tools, but as an exercise it might be fun.

>> Also a quick question on the patch below - if you're running
>> postscreen, and it has decided a sending host is "bad", will the
>> connection ever hit the real smtpd daemon and be logged?
> 
> Postfix always includes the helo (if available) in a reject log
> entry, whether the reject happens in postscreen or elsewhere. No
> patch needed for that.

Good to know, thanks.  Wietse confirmed what I was assuming was
true, that in the very specific case of the patch that was posted,
it would not see any connections that postscreen blocked.

Thanks,

Charles

> 
> 
> 
>  -- Noel Jones
> 
>> 
>> Thanks,
>> 
>> Charles
>> 
>> ps - I lurk here and just wanted to say "thanks" to all for postfix
>> and the list denizens.  I just started work on putting an old
>> qmail/vpopmail setup behind postfix and I'm just consistently blown
>> away by the flexibility of postfix - it's hard to find an unsolvable
>> problem.
>> 
>>> 
>>> Sample log entry:
>>> Feb 25 08:40:39 mx1 postfix/smtpd[30241]: NOQUEUE:
>>> client=mail.example.com[192.2.0.2], helo=mail.example.com
>>> 
>>> Note the modified log entry may break some log parsers, but is
>>> compatible with pflogsumm.pl and postfix-logwatch.
>>> 
>>> 
>>> (beware line wrapping)
>>> 
>>> --- /usr/local/src/postfix-2.8-20100728/src/smtpd/smtpd.c       Mon
>>> Jul 26 18:39:39 2010
>>> +++ src/smtpd/smtpd.c   Tue Aug 10 16:42:36 2010
>>> @@ -1916,13 +1916,16 @@
>>> #define PRINT2_OR_NULL(cond, name, value) \
>>>           PRINT_OR_NULL((cond), (name)), PRINT_OR_NULL((cond),
>>> (value))
>>> 
>>> -       msg_info("%s: client=%s%s%s%s%s",
>>> +       msg_info("%s: client=%s%s%s%s%s%s%s%s%s",
>>>                (state->queue_id ? state->queue_id : "NOQUEUE"),
>>>                state->namaddr,
>>>                PRINT2_OR_NULL(HAVE_FORWARDED_IDENT(state),
>>>                               ", orig_queue_id=",
>>> FORWARD_IDENT(state)),
>>>                PRINT2_OR_NULL(HAVE_FORWARDED_CLIENT_ATTR(state),
>>> -                               ", orig_client=",
>>> FORWARD_NAMADDR(state)));
>>> +                               ", orig_client=",
>>> FORWARD_NAMADDR(state)),
>>> +                ", helo=", state->helo_name ? state->helo_name : "",
>>> +                PRINT2_OR_NULL(HAVE_FORWARDED_CLIENT_ATTR(state),
>>> +                               ", orig_helo=",  FORWARD_HELO(state)
>>> ? FORWARD_HELO(state) : ""));
>>>    return (0);
>>> }
>>> 
>>> --- /usr/local/src/postfix-2.8-20100728/src/smtpd/smtpd_sasl_proto.c
>>>  Mon Jul 26 18:40:14 2010
>>> +++ src/smtpd/smtpd_sasl_proto.c        Tue Aug 10 17:56:42 2010
>>> @@ -243,7 +243,7 @@
>>> #define PRINT2_OR_NULL(cond, name, value) \
>>>           PRINT_OR_NULL((cond), (name)), PRINT_OR_NULL((cond),
>>> (value))
>>> 
>>> -    msg_info("%s: client=%s%s%s%s%s%s%s%s%s%s%s",
>>> +    msg_info("%s: client=%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s",
>>>            (state->queue_id ? state->queue_id : "NOQUEUE"),
>>>            state->namaddr,
>>>            PRINT2_OR_NULL(state->sasl_method,
>>> @@ -255,7 +255,10 @@
>>>            PRINT2_OR_NULL(HAVE_FORWARDED_IDENT(state),
>>>                           ", orig_queue_id=", FORWARD_IDENT(state)),
>>>            PRINT2_OR_NULL(HAVE_FORWARDED_CLIENT_ATTR(state),
>>> -                           ", orig_client=", FORWARD_NAMADDR(state)));
>>> +                           ", orig_client=", FORWARD_NAMADDR(state)),
>>> +            ", helo=", state->helo_name ? state->helo_name : "",
>>> +            PRINT2_OR_NULL(HAVE_FORWARDED_CLIENT_ATTR(state),
>>> +                           ", orig_helo=",  FORWARD_HELO(state) ?
>>> FORWARD_HELO(state) : ""));
>>> }
>>> 
>>> /* smtpd_sasl_mail_reset - SASL-specific MAIL FROM cleanup */
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> -- Noel Jones
>> 
> 

Reply via email to