logs analisys
Problem reported by Sabatino - 1/17/2026 at 3:55 PM
Submitted
Hi guys. I've asked SM several times to improve the log reporting, but I understand they have other priorities.
I've found some time to dedicate to the project and now I have a first draft.

The current goal is to identify anomalies such as:
1) IPs that have many or only few authentication failures (to be blacklisted)
Among these, there could be IPs that have many failures on many emails and few successes on some emails (compromised email?)

You'll say, "But there are ID rules." Yet I've seen many IPs that are slowly trying to detect ID rules.

I still have a lot to do:
- blacklisting IPs via API.
- IP normalization, meaning looking for ranges of IPs instead of individual IPs to blacklist.

I'll show you some screenshots to give you an idea.








It's a web app in DoNet Core 10.

Currently tested only in IIS.

Ideas for new reports are welcome.

Another thing I'll definitely do is real-time log analysis.

That is, a screen that collects an SMTP session in a single view, which then becomes a delivery, passing through an anti-spam check.

Perhaps with IP filtering.

Imagine, a user calls who's having problems: give me your IP, we'll see what happens.

And I can track it in real time in a single screen.
Sabatino Traini
      Chief Information Officer
Genial s.r.l. 
Martinsicuro - Italy

Sabatino Replied


I moved on.
I connected MaxMind GeoIP, so now the system identifies the origin.

Now it also gives me statistics based on country.
For example, from this one I saw that I had many login attempts from India, but no successful attempts. So I'd say I can rule out India.
I've connected the system to SM's blacklists. For now, it only tells me if an IP has already been blacklisted, and it can also analyze the blacklists to find redundancies (individual IPs already blacklisted, or identify ranges). There's still a lot of work to do.

Considering India, blacklisting a range also prevents it from sending messages to mail server users.
It's also true that if these are IPs making unauthorized inbound attempts, that's fine.
However, I'd like to block SMTP authentication for Indian IPs for all domains. I don't have this option. I'd have to manually (or with a script) edit all the domains.



It's also true that many authentication attempts occur without specifying the domain,
so with
info
and not with info@domain.tld.

The by-country block doesn't work here.


If anyone wants to try the web app, send me a private message and I'll send it to you.
Remember, it works with DotNet Core 10. I've currently tested it with IIS.

Use SQL Lite or SQL Server.


Sabatino Traini Chief Information Officer Genial s.r.l. Martinsicuro - Italy
J. LaDow Replied
This looks very interesting!
MailEnable survivor / convert --
Sabatino Replied
To-do list:
- Blacklist management
- Real-time analysis of user sessions (from SMTP to anti-spam to delivery) in a single screen with IP filtering
- Delivery log analysis (trying to answer questions that currently give me a headache): accounts that are sending to unknown users above a certain limit, accounts exceeding the usual daily average, accounts with aliases/forwards (which ones, how many, correlation with sending to unknowns)

And more
Sabatino Traini Chief Information Officer Genial s.r.l. Martinsicuro - Italy
Reto Replied
Hi Sabatino

This looks very interesting and well done. Do you use the local maxmind database from SM?

Best Regards,
Reto
Sabatino Replied
No. After registering for free on the website https://www.maxmind.com/en/geolite2/signup and obtaining an API key, the webapp is independent, downloads and keeps its own copy of the database updated.

Sabatino Traini Chief Information Officer Genial s.r.l. Martinsicuro - Italy
Reto Replied
Beeing different versions there will be differences in the data.I had this already in the past, the country was not correct in sm. Especially as the sm maxmind database is/was not frequently updated. The local version would give you the same data, no account registration needed and i assume less resources used when many lookups are done. 
Sabatino Replied
The web app, as per the Maxmind license specifications, keeps the local database updated with the latest version on the Maxmind website.
Downloads a version locally, but does so continuously and at least once a week.
Sabatino Traini Chief Information Officer Genial s.r.l. Martinsicuro - Italy
J. LaDow Replied
In other words, Sabatino's Country data will generally be more up to date as it updates internally.

SM's data will only be updated when they update the database that is compiled directly into the SM binaries -- 

Interested in looking at this -- we were going to start rolling our own but could contribute to this instead --
MailEnable survivor / convert --
When using Office365 logging and going back to Smartermail is a WTF! feeling....

It needs so muuuuuuuuch.....
Sabatino Replied
Here you go.

Thanks in advance to anyone who has the time and inclination to try it and offer suggestions.

I remind you that it's a web app that must be installed in IIS on the same server as SM, as it needs access to the log directory.

In the initial wizard, you can choose SQL Lite so you don't have any dependencies on external databases.

Since it's built in .NET Core 10, there's nothing that could potentially prevent it from running on Linux, but I haven't tried it.
Sabatino Traini Chief Information Officer Genial s.r.l. Martinsicuro - Italy
Montague WebWorks Replied
Wow. Yes, please. Looking at my Administrative logs (without search criteria) I see a sea of failed user attempts, with the same username but a variety of IP numbers (hard to block) and single IPs trying many un/pw (easily blocked), and also see other definite patterns that could be automated for blocking.

> a screen that collects an SMTP session in a single view, which then becomes a delivery, passing through an anti-spam check.

YES YES YES. I get calls occasionally from clients who want to know why they either didn't receive an email or an email they sent wasn't received. These sessions typically involve a few log files, so tracking the life-span of a session -- including through Declude -- would be a game changer for support.

Keep working on it!
Mik MullerMontague WebWorks
Sabatino Replied
In the meantime, I've added some screenshots I've always been looking for.
One is this one.

It also contains a list of domains with a column listing the authorized or blocked countries.

The idea is to select multiple domains and set blocks or authorizations, perhaps managing country groups (Europe, Asia, etc.).

Another one is this.
I've been looking for a comprehensive overview of users who are close to their limit without having to open each individual domain.


Sabatino Traini Chief Information Officer Genial s.r.l. Martinsicuro - Italy
Reto Replied
@Sabatino Thanks, looks very good. 

Had it first as a subdirectory, but requests did miss the subdirectory name in the urls trough the setup. I changed it to a own site to resolve the problem. On my desktop i have a loop requesting http://192.168.1.1:82/SetLanguage?culture=en-US&returnUrl=%2F over and over again. But on the server it's working with 127.0.0.1:82. 

Really helpful, found already many intersting things. Good work. 
Montague WebWorks Replied
Looking through the Administrative logs is a real eye-opener. Open today's log with no search criteria, download the file, then pop it into your favorite text editor, sorting on the 14th character (the IP number, most of the time). If you remove the extra lines at the top and bottom then scroll through the file from the top down, you'll frequently see loooooooong swaths of log-in attempts throughout the day from the same IP numbers. On my system they typically try to do a POP login with these 16 common user addresses:

admin, billing, contact, customer, finance, hr, news, noreply, no-reply, postfix, sales, service, shop, support, test, webmaster.

For instance (all China):

04:16:41.055 [106.53.161.136] POP Attempting to login user: admin@aaaa.org
04:21:14.870 [106.53.161.136] POP Attempting to login user: admin@bbbb.org
04:23:36.921 [106.53.161.136] POP Attempting to login user: admin@cccc.net
04:26:04.121 [106.53.161.136] POP Attempting to login user: admin@dddd.com
04:30:10.068 [106.53.161.136] POP Attempting to login user: admin@eeee.com
04:36:45.891 [106.53.161.136] POP Attempting to login user: admin@fffff.com
04:39:27.924 [106.53.161.136] POP Attempting to login user: admin@gggg.org
...
11:38:57.044 [106.53.161.136] POP Attempting to login user: webmaster@aaaa.org
11:43:15.911 [106.53.161.136] POP Attempting to login user: webmaster@bbbb.org
11:45:34.070 [106.53.161.136] POP Attempting to login user: webmaster@cccc.net
11:47:54.212 [106.53.161.136] POP Attempting to login user: webmaster@dddd.com
11:51:48.859 [106.53.161.136] POP Attempting to login user: webmaster@eeee.com
11:57:58.092 [106.53.161.136] POP Attempting to login user: webmaster@ffff.com
12:00:35.041 [106.53.161.136] POP Attempting to login user: webmaster@gggg.org

Total of 210 failed attempts, just from this one IP. You can average these fails around, say, twelve users x six domains per IP, often trying three times a day on each. Most of the time, it's more.

So far I've found these IPs (below) exhibiting that behavior (only about 5% through the file so far), likely all from China. I already have them on the blocked country list, but these IPs appear to not be included in that:

1.212.225.99
1.234.70.54
101.47.73.6
102.130.121.204
102.210.148.98
102.218.10.150
102.53.15.17
102.53.15.18
102.53.15.56
103.106.104.187
103.121.199.166
103.154.231.122
103.244.206.6
103.74.54.116
103.81.87.161
104.207.65.226
106.14.31.49
106.51.67.60 110.93.25.38 112.213.125.12 116.118.47.174 (300+ attempts in 12 hours) 118.219.255.169 (150+ attempts in 12 hours) 125.212.235.151 134.119.183.213 Each of these IPs had more then one hundred failed attempts over the course of the first half of today (midnight to noon). This is only a fraction of the total list.

I would love to have some automated intelligence looking at these trends and permanently blocking an IP number if it fails more then 50 times hitting multiple domains in a day. Seems obvious. But, how?

BTW, I am continually amazed at how many failed attempts come from China. And... why so many attempts at a user named "e9ginpfa-1klghsfw" from so many IPs? Any IP trying to log in with that user name should automatically be barred for life.
Mik MullerMontague WebWorks
J. LaDow Replied
We employ a 3rd party log scanner and some regex to detected failed logins, and IDS triggers then block at our edge.  DigitalRuby's IPBan (works on Linux and Windows hosts) --

You'd have to come up with your own 'recipes' for reading SM logs, and you would want to make sure and safelist your IPs before you enable / test the settings.
MailEnable survivor / convert --
Montague WebWorks Replied
Ok, I downloaded today's Administrative log through 1:00 PM, removed every line except for the POP and SMTP login fails, and dropped it into a DB table, then ran a quick query and got this: num fails, IP

SELECT distinct ipnum, count(ipnum) as c
  FROM [tbl_Log]
  group by ipnum
  order by c desc
Here are the IPs with 25 or more fails between 00:00:01 and 13:00:00 today.

count	ipnum
203	116.118.47.174
165	198.11.183.50
160	51.79.54.139
153	202.93.247.247
151	186.69.247.106
126	162.240.229.246
124	202.10.36.52
124	35.186.147.126
120	157.66.47.242
119	103.74.54.116
115	102.210.148.98
106	186.236.237.105
104	213.209.159.42
103	27.71.16.87
103	118.219.255.169
100	102.130.121.204
100	47.254.85.115
97	82.196.100.25
95	1.234.70.54
94	50.6.229.145
93	95.217.129.37
90	203.161.55.17
90	47.240.57.60
89	47.236.28.137
88	47.88.19.82
86	174.192.9.246
81	139.59.27.50
81	103.154.231.122
76	213.209.159.12
75	209.38.71.25
72	210.114.19.39
70	43.225.52.87
66	103.121.199.166
65	162.240.100.50
65	157.66.219.178
64	112.213.125.12
64	165.22.121.69
63	103.106.104.187
60	209.74.81.91
60	103.244.206.6
59	47.57.236.167
58	167.99.52.76
55	125.212.235.151
54	92.205.128.246
54	216.10.250.47
54	110.93.25.38
47	20.40.45.20
42	173.76.40.244
40	76.118.51.106
36	91.98.226.124
35	103.81.87.161
33	66.116.199.47
33	73.249.52.211
33	203.251.202.80
33	66.116.199.61
32	206.81.30.59
32	14.206.12.13
32	212.4.112.156
32	102.218.10.150
31	162.240.166.197
31	141.94.22.51
31	45.55.58.157
31	51.77.195.243
31	47.245.147.175
30	51.210.107.22
30	202.91.32.108
30	64.227.166.74
30	66.116.204.232
29	8.211.28.246
29	81.10.59.26
29	104.207.65.226
29	211.57.200.145
29	165.232.179.250
28	107.189.50.146
27	101.47.73.6
27	47.79.151.22
26	159.89.164.156
26	173.166.46.131
25	105.174.17.50
Mik MullerMontague WebWorks
Sabatino Replied
here is the new version
https://we.tl/t-rMkanx55L1

1) Added SM domain display
2) Added SM user display
3) Fixed the infinite loop issue with setlanguage @RETO


Sabatino Traini Chief Information Officer Genial s.r.l. Martinsicuro - Italy
Sabatino Replied
The goal is precisely that: to make these types of data readable, also comparing whether the same IP has performed successful authentications for the same period of time.

Let me explain.
If an IP has performed 1,000 authentications on 100 accounts and 10 successful authentications on two accounts over a period of 3 days, it should be investigated. Are the successful authentication accounts compromised?

What I don't understand about your reasoning, however, is that you're referring to the administrative log. So you raised a doubt, and I checked mine (I mean the yyyy.mm.dd-administrative.log log),
which I've configured in detail.

I checked on 2026.01.21 and found the following in the log 2026.01.21-smtpLog.log:


 
[2026.01.21] 00:06:28.942 [89.252.159.243][19826035] rsp: 535 Authentication failed
[2026.01.21] 00:10:08.106 [89.252.159.243][2259030] rsp: 535 Authentication failed
[2026.01.21] 00:12:06.057 [89.252.159.243][18483379] rsp: 535 Authentication failed
[2026.01.21] 00:12:44.296 [89.252.159.243][58629832] rsp: 535 Authentication failed
[2026.01.21] 00:23:43.148 [89.252.159.243][1191222] rsp: 535 Authentication failed
[2026.01.21] 00:39:13.090 [89.252.159.243][48719439] rsp: 535 Authentication failed
[2026.01.21] 00:56:50.543 [89.252.159.243][14620738] rsp: 535 Authentication failed
[2026.01.21] 01:02:31.201 [89.252.159.243][66379041] rsp: 535 Authentication failed
[2026.01.21] 01:04:13.955 [89.252.159.243][32107509] rsp: 535 Authentication failed
[2026.01.21] 01:11:59.514 [89.252.159.243][23107260] rsp: 535 Authentication failed
[2026.01.21] 01:19:00.265 [89.252.159.243][62950099] rsp: 535 Authentication failed
[2026.01.21] 01:20:48.970 [89.252.159.243][19102728] rsp: 535 Authentication failed
[2026.01.21] 01:24:38.507 [89.252.159.243][52989246] rsp: 535 Authentication failed
[2026.01.21] 01:29:40.073 [89.252.159.243][34262558] rsp: 535 Authentication failed
[2026.01.21] 01:44:32.613 [89.252.159.243][59121721] rsp: 535 Authentication failed
[2026.01.21] 01:47:13.872 [89.252.159.243][21684753] rsp: 535 Authentication failed
[2026.01.21] 01:56:54.729 [89.252.159.243][14002760] rsp: 535 Authentication failed
[2026.01.21] 02:02:21.422 [89.252.159.243][14108430] rsp: 535 Authentication failed
[2026.01.21] 02:04:03.250 [89.252.159.243][42975668] rsp: 535 Authentication failed
[2026.01.21] 02:08:31.973 [89.252.159.243][20866993] rsp: 535 Authentication failed
[2026.01.21] 02:09:38.047 [89.252.159.243][29342155] rsp: 535 Authentication failed
[2026.01.21] 02:16:15.512 [89.252.159.243][8920808] rsp: 535 Authentication failed
[2026.01.21] 02:19:58.483 [89.252.159.243][23608611] rsp: 535 Authentication failed
[2026.01.21] 02:25:57.456 [89.252.159.243][63456514] rsp: 535 Authentication failed
[2026.01.21] 02:27:24.524 [89.252.159.243][42720730] rsp: 535 Authentication failed
[2026.01.21] 02:40:56.748 [89.252.159.243][55781910] rsp: 535 Authentication failed
[2026.01.21] 02:44:49.737 [89.252.159.243][48108459] rsp: 535 Authentication failed
[2026.01.21] 02:52:35.970 [89.252.159.243][30291958] rsp: 535 Authentication failed
[2026.01.21] 03:04:51.594 [89.252.159.243][12003290] rsp: 535 Authentication failed
[2026.01.21] 03:25:09.014 [89.252.159.243][63704225] rsp: 535 Authentication failed
[2026.01.21] 03:27:58.932 [89.252.159.243][52900252] rsp: 535 Authentication failed
[2026.01.21] 03:32:49.164 [89.252.159.243][22738702] rsp: 535 Authentication failed
[2026.01.21] 03:50:21.381 [89.252.159.243][41793435] rsp: 535 Authentication failed
[2026.01.21] 03:57:48.872 [89.252.159.243][27949943] rsp: 535 Authentication failed


...
...

While I have no occurrences in 2026.01.21-administrative.log for the same IP.

Auth fails are in 2026.01.21-smtpLog.log, or something is wrong with my installation.
Sabatino Traini Chief Information Officer Genial s.r.l. Martinsicuro - Italy
Sabatino Replied
To clarify, I opened a ticket and here's the response:

The administrative log does not record every SMTP auth attempt - this is by design, so as to not pollute the admin logs. The SMTP log is the correct place to look for SMTP auth attempt records.


So, the auth fails must be looked for in the SMTP log.
Sabatino Traini Chief Information Officer Genial s.r.l. Martinsicuro - Italy

Reply to Thread

Enter the verification text