Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DNSBL server notices should always show a real nickname #804

Closed
UselessOper opened this issue Mar 23, 2014 · 5 comments
Closed

DNSBL server notices should always show a real nickname #804

UselessOper opened this issue Mar 23, 2014 · 5 comments
Labels
discussion Discussion about the behaviour of InspIRCd

Comments

@UselessOper
Copy link

These server notices are useful:

23:03 [irc.] !irc. *** ANNOUNCEMENT: Connecting user John!John@0.0.0.0 detected as being on a DNS blacklist (cbl.abuseat.org) with result 2

These server notices are not useful:

23:03 [irc.] !irc. *** ANNOUNCEMENT: Connecting user 851AAMMWE!unknown@0.0.0.0 detected as being on a DNS blacklist (cbl.abuseat.org) with result 2

Once an IRC operator sees a DNSBL server notice that shows a real nickname, if a user with the same nickname connects shortly after but doesn't get banned then it's likely that it's the same user on another proxy etc. that simply isn't listed so the user can be dealt with manually.

I'm guessing this is something to do with the speed in which a DNSBL replies. If it replies quickly and the user hasn't had chance to send a nickname then it shows the UID. That's just a guess, I really have no idea.

So, is it possible that it can always show a real nickname?

@attilamolnar
Copy link
Member

I'm guessing this is something to do with the speed in which a DNSBL replies. If it replies quickly and the user hasn't had chance to send a nickname then it shows the UID. That's just a guess, I really have no idea.

This is correct and is what is happening here. The user's default nick is their uid, and the default ident is "unknown". This means this cannot be fixed, unless you are willing to wait and process commands from a user who is going to go away anyway.

@UselessOper
Copy link
Author

@attilamolnar Yes I agree that it is pointless to process anything more than what is necessary for a user who is going to go away anyway, but what is even more pointless is sending a server notice telling IRC operators I have no idea who, but someone tried to connect and I banned them. For the points in my original post regarding tracking etc. I do believe that there should be some sort of delay so that, at the least, a useful server notice is sent.

@attilamolnar
Copy link
Member

Do you mean you don't see the IP?

@JDowny
Copy link

JDowny commented Mar 24, 2014

I understand the logic behind what you are requesting, and in some ways I think this may be useful; however... I feel that during large bot runs this is really just a waste of resources because you don't at all care what the nicks are.

@UselessOper
Copy link
Author

@attilamolnar Yes it shows the IP address as intended but for the sake of ease it is much easier to track future bad connections if it always showed a nickname i.e. "I'm sure he/she connected a moment ago on a proxy ...". I understand what @JDowny is also saying, but would it not be possible to at least have some sort of configuration option for those who want the user disconnected as soon as possible and those who want to wait for the user to provide a nickname etc.?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Discussion about the behaviour of InspIRCd
Development

No branches or pull requests

4 participants