A. Schulze:
>
> A. Schulze:
>
> > Am 18.09.2016 um 14:39 schrieb Wietse Venema:
> >> As in the patch below.
>
> Hello Wietse,
>
> there are multiple places where such loglines are written:
Those are irrelevant, because they either happen after smtpd has
already logged the sasl user name, or be
A. Schulze:
Am 18.09.2016 um 14:39 schrieb Wietse Venema:
As in the patch below.
Hello Wietse,
there are multiple places where such loglines are written:
$ find . -name '*.c' | xargs grep helo=
./src/cleanup/cleanup_message.c:
vstring_sprintf_append(state->temp1, " helo=<%s>", att
Am 18.09.2016 um 14:39 schrieb Wietse Venema:
As in the patch below.
ups, you'r so fast...
thanks!
I'll try and report.
Andreas
Am 18.09.2016 um 14:31 schrieb Wietse Venema:
No, that would log it too often in normal sessions. Instead it can
be logged for rejected commands.
reject: from host[addr] ...; from=, to=, proto=SMTP,
helo=, sasl_username=
Hello Wietse,
that would be OK, too.
It requires a code change
Wietse Venema:
> No, that would log it too often in normal sessions. Instead it can
> be logged for rejected commands.
>
> reject: from host[addr] ...; from=, to=, proto=SMTP,
> helo=, sasl_username=
As in the patch below.
Wietse
diff -u /var/tmp/postfix-3.2-20160917/src/smtpd/s
A. Schulze:
>
> Hello,
>
> we implemented a submission server with SASL authentication. nothing
> special...
> also we use to grep for "sasl_username=$customer_with_trouble".
>
> today I noticed, the successful authentication was not logged
> because a sender address was rejected. Looks like s
Hello,
we implemented a submission server with SASL authentication. nothing special...
also we use to grep for "sasl_username=$customer_with_trouble".
today I noticed, the successful authentication was not logged because a sender
address was rejected.
Looks like sasl_username logging happen on
