Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

getting username from failed AUTH attempts from milter

20 views
Skip to first unread message

Ed Wong

unread,
May 24, 2023, 9:40:11 PM5/24/23
to
Hi,

This question is somewhat similar to https://groups.google.com/g/comp.mail.sendmail/c/nwomWJzMwWA/m/salF0uH-2_4J in that instead of the IP, I'd like to get the username from within a milter. From the linked
message, the UN and PW is passed to saslauthd and the return is the pass/failed status.

This means sendmail does know the UN. Is there a way for a milter to extract this UN information?

I'm looking at the logs and the AUTH failure happens between the hello
callback and the envfrom callback (which never gets called) since by the time AUTH failure is encountered, the connection is dropped. And using smfi_getsymval() to get "{auth_author}", I get None for the value. (note, I used smfi_getsymval() in the hello cb (which isn't available as mentioned in https://github.com/aosm/sendmail/blob/0b43ef09c7fa82f822b17cb8a060f673280663cc/sendmail/libmilter/docs/smfi_getsymval.html) and the connection doesn't get to envfrom.

Any clarifications appreciated.


Ed

Claus Aßmann

unread,
May 25, 2023, 1:58:12 AM5/25/23
to
"What's the problem you are trying to solve?"
Why do you want to access that data?

${auth_authen}
The client's authentication credentials as deter-
mined by authentication (only set if successful).
^^^^^^^^^^^^^^^^^^^^^^


--
Note: please read the netiquette before posting. I will almost never
reply to top-postings which include a full copy of the previous
article(s) at the end because it's annoying, shows that the poster
is too lazy to trim his article, and it's wasting the time of all readers.

Otto J. Makela

unread,
Jul 21, 2023, 5:11:14 AM7/21/23
to
Claus Aßmann wrote:

> "What's the problem you are trying to solve?"
> Why do you want to access that data?
>
> ${auth_authen}
> The client's authentication credentials as deter-
> mined by authentication (only set if successful).
> ^^^^^^^^^^^^^^^^^^^^^^

I don't know about Ed's situation, but I would certainly like to be able
to discern these two situations (assuming no bandwith limitations) from
each other:

* user has an incorrect password in their (badly behaving) email client,
which keeps repeatedly hammering our server with the same username

* compromised host is doing a dictionary attack over all our users

If I understood correctly, if the attempted authentication credentials
are not stored in the logs, how do you tell these apart?

And then there's the kinda opposite case of a large botnet hammering the
server with an exhaustive search for a single account password.

--
/* * * Otto J. Makela <o...@iki.fi> * * * * * * * * * */
/* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */
/* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */
/* * * Computers Rule 01001111 01001011 * * * * * * */

Claus Aßmann

unread,
Jul 21, 2023, 12:25:17 PM7/21/23
to
Otto J. Makela wrote:

> If I understood correctly, if the attempted authentication credentials
> are not stored in the logs, how do you tell these apart?

8.16.1/8.16.1 2020/07/05

Log user= for failed AUTH attempts if possible. Based on
patch from Packet Hack, Jim Hranicky, Kevin A. McGrail,
and Joe Quinn.

If that's not good enough: check what Cyrus-SASL does.
0 new messages