Clarification on 'unknown user' log entries

Hi,
I read about this being normal, but as worded in the help article : http://help.directadmin.com/item.php?id=175 it seems there would be one error logged for a valid user.

RE:

A valid email account of either type will only exists in one of these database, not both, but both are checked to attempt to validate the user. If the email account does not exist in the first one, then the error will show up, even though it exists in the 2nd database. This is normal.

Click to expand...

I'd consider the following two errors.
It's sort of confusing anyhow since "spook" is listed in /etc/virtual/domain.com/passwd however, not [email protected] -- which I guess makes the two errors applicable?

I'm splitting hairs here I know, but seems keeping this logging -on- could be of value, just would be nice to filter out the noise of the above and still log 'legitimate' errors for cases where the log entries could help.

Boils down to wishing the massive amount of these 'fake' errors wouldn't get logged, but would prefer to not disable any logging that could help solve a problem down the road.. No sort of middle-ground here?

Why does it matter if it works?

Disabling the log levels like it says in the KB still logs failed attempts, so e.g. CSF can still do it's job. Successful logins are also still logged so you can see what's going on.

The debugging levels don't need to be so high for production use.

My guess is someone was too lazy to remove un-needed lines in the dovecot config.

Just a WAG: Possibly dovecot is checking multiple places for login password, since an email login can be either a virtual account (email@example.com) or system user without the domain name (username). so it checks first one place, and then if not found the other.

Or am I misreading something?

Jeff

nobaloney said:

Just a WAG: Possibly dovecot is checking multiple places for login password, since an email login can be either a virtual account (email@example.com) or system user without the domain name (username). so it checks first one place, and then if not found the other.

Or am I misreading something?

Jeff

Click to expand...

That's correct. This topic kind of says everything what's in the KB already; the misunderstanding was that the TS thought that disabling certain logging settings as suggested in the KB article would disable valuable logging altogether.

Arieh said:

That's correct. This topic kind of says everything what's in the KB already; the misunderstanding was that the TS thought that disabling certain logging settings as suggested in the KB article would disable valuable logging altogether.

Click to expand...

Precisely what my concern was. I've since posting here, have adjusted the auth_debug config selection mentioned in the KB to "no" -- guess I probably shouldn't blindly consider working 'out of box' configs best, and start researching about and checking them.

I have admittedly not approached how I can adjust the logging & rollover characteristics, nor the details of how my changing their operation could/would impact things besides the obvious.

An alterior motive was/is to take more control of automated logging retention and rollover somehow. Some of the logs appear to cycle rollover in short order where I was hunting something in the log but the particular segment had already been rolled out of the system.

This is pretty much why it mattered at all to me. I can't remember where, but there is also somewhere here or in versions or the KB about log(s) retention and rollover being adjusted 'shorter' by default which I was thinking of. Thus, more efficient use of logs by DA and the rest of the software has some importance IMO... further thinking JBMC had done some optimzing to make up for less logs -- thus, presumably JBMC considered these dovecot settings appropriatly set.

I think SCSI has hit the nail on the head though. Unfortunantly I am not yet familiar enough with all the config files to adjust them very much with adequate confidense.

Thanks everyone for the input. It's been a big help.