mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Aug 2003
Posts: 319
P
Pan-dimensional mouse
OP Offline
Pan-dimensional mouse
P
Joined: Aug 2003
Posts: 319
Code:
/whois dragnbreaker
dragnbreaker is dragnbreake@ihw-lhjeof.dhcp.embarqhsd.net
dragnbreaker using *.irchighway.net irchighway
dragnbreaker End of /WHOIS list.

Code:
//echo -s $address(dragnbreaker,5)
dragnbreaker!ragnbreake@ihw-lhjeof.dhcp.embarqhsd.net


Not sure also about whether this is correct either:
Code:
//echo -s $address(dragnbreaker,6)
dragnbreaker!*agnbreake@ihw-lhjeof.dhcp.embarqhsd.net

Joined: Jul 2006
Posts: 4,145
W
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,145
Hello, these results looks fine, see /help $mask for a description of each number


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Aug 2003
Posts: 319
P
Pan-dimensional mouse
OP Offline
Pan-dimensional mouse
P
Joined: Aug 2003
Posts: 319
Originally Posted By: Wims
Hello, these results looks fine, see /help $mask for a description of each number


I checked the help file $mask.

The difference is small but exists:
Code:
//echo -s $address(dragnbreaker,5)
Is:        dragnbreaker!ragnbreake@ihw-lhjeof.dhcp.embarqhsd.net
Should be: dragnbreaker!dragnbreake@ihw-lhjeof.dhcp.embarqhsd.net


i.e. the leading "d" is missing from the user part of the address.

Joined: Jul 2006
Posts: 4,145
W
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,145


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Aug 2003
Posts: 319
P
Pan-dimensional mouse
OP Offline
Pan-dimensional mouse
P
Joined: Aug 2003
Posts: 319
Originally Posted By: Wims


Apologies - I didn't read as far back as 9 years ago to discover that the issue had been previously reported.

Yes - I accept that the IRC RFCs may specify usernames up to 9 characters, however:

1. mIRC itself allows userids of up to 10 characters on the IDENT options page. $address(nick,5) works on these, but $address(nick,6) still truncates the first character.

2. As stated in that link, the RFC states "While the maximum length is limited to nine characters, clients SHOULD accept longer strings as they may become used in future evolutions of the protocol." and mIRC doesn't follow this.

3. I found this because I use the $address(nick,5) to add addresses to the DCC trust list and DCC sends were failing - so mIRC is inconsistent in its handling of userids longer than 10 characters, using the full userid when comparing with the trust list but only the first 10 characters when providing it in $address(nick,5).

4. Perhaps, as mIRC already does in many other cases, mIRC needs to have adjustments to work with real-life servers which are outside the formal spec in minor ways like this.

Joined: Apr 2004
Posts: 871
Sat Offline
Hoopy frood
Offline
Hoopy frood
Joined: Apr 2004
Posts: 871
For starters: I'm not criticizing your bug report here - I think you make a fair point and I am impartial to the outcome. However, I think that a bit of clarification is in order..

Originally Posted By: Protopia
Yes - I accept that the IRC RFCs may specify usernames up to 9 characters

They do not. The people in that old thread confuse nicknames and usernames, drawing an incorrect link between the two. They are fully independent.

Technically, the RFCs (1459, and 2812 if you care about IRCnet in particular) define the username length as being unbounded. The widely accepted de-facto standard username length limit is exactly 10 characters, however. No more, no less. There are virtually no networks with username length limits other than ten characters. mIRC currently follows this de-facto limit as well.

Quote:
1. mIRC itself allows userids of up to 10 characters on the IDENT options page. $address(nick,5) works on these, but $address(nick,6) still truncates the first character.

Given the above limit, that makes perfect sense.

Quote:
2. As stated in that link, the RFC states "While the maximum length is limited to nine characters, clients SHOULD accept longer strings as they may become used in future evolutions of the protocol." and mIRC doesn't follow this.

This is again referring to nicknames. See above: one could argue that mIRC is not following the RFCs, but it is not this statement that is relevant.

Quote:
4. Perhaps, as mIRC already does in many other cases, mIRC needs to have adjustments to work with real-life servers which are outside the formal spec in minor ways like this.

I don't disagree, although I think it's also rather stupid for those servers to mess with well-established de-facto standards. Such changes are likely to cause problems with more than just mIRC.


Saturn, QuakeNet staff
Joined: Aug 2003
Posts: 319
P
Pan-dimensional mouse
OP Offline
Pan-dimensional mouse
P
Joined: Aug 2003
Posts: 319
Agreed.

1. mIRC should continue to limit userids to 10 characters

2. mIRC should ideally allow userids > 10 characters in $address(nick,5) as there is no downside to doing this.

3. If mIRC does not allow userids > 10 characters in $address(nick,5), then it needs to be consistent with how it truncates it for $address and for checking DCC Trust and for showing whois output etc.

Last edited by Protopia; 19/07/17 10:31 AM.
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
This is not related to the RFC. IRC clients have had to adapt over the years to cater for server implementations that go beyond the RFC. In this case, I mentioned the reason in my post:

Quote:
If I recall correctly, at one time mIRC did store more than nine characters for the user string, however due to bug reports relating to that behaviour mIRC was changed to comply with the maximum length. I can't remember the reason for the original bug report unfortunately apart from the fact that there were side-effects on some IRC networks when the maximum length was not enforced.

While I could revert this change, this will result in the same issue that users reported years ago that led to this change in the first place.

Quote:
1. mIRC itself allows userids of up to 10 characters on the IDENT options page. $address(nick,5) works on these, but $address(nick,6) still truncates the first character.

$mask() was made to work this way based on input from users who were having issues with servers that could not handle long userids. Anything beyond 9 characters is chopped to nine characters and prefixed with a wildcard.

Quote:
2. As stated in that link, the RFC states "While the maximum length is limited to nine characters, clients SHOULD accept longer strings as they may become used in future evolutions of the protocol." and mIRC doesn't follow this.

mIRC did follow this - it originally had no limit. However, as different server implementations used different methods, and were affected in different ways by userids longer than nine characters, there was no other way to prevent these issues.

Quote:
3. I found this because I use the $address(nick,5) to add addresses to the DCC trust list and DCC sends were failing - so mIRC is inconsistent in its handling of userids longer than 10 characters, using the full userid when comparing with the trust list but only the first 10 characters when providing it in $address(nick,5).

If you can provide a step by step method of reproducing this issue, so that I can see where it is being inconsistent, I will try to reproduce it here. Note that any further changes will need to chop the userid to 9 characters.

Joined: Apr 2004
Posts: 871
Sat Offline
Hoopy frood
Offline
Hoopy frood
Joined: Apr 2004
Posts: 871
Originally Posted By: Khaled
If I recall correctly, at one time mIRC did store more than [ten] characters for the user string, however due to bug reports relating to that behaviour mIRC was changed to comply with the maximum length. I can't remember the reason for the original bug report unfortunately apart from the fact that there were side-effects on some IRC networks when the maximum length was not enforced.

Most probably the issue was ban masks. Many server implementations limit the username part of ban masks to the username length. For example: if you attempt to ban *!*1234567890@* on a server with USERLEN=10, the ircd may set the ban *!*123456789@* instead. This is why it is essential to keep enforcing the correct limit, and instead ban *!*234567890@* on such networks. That affects the way $mask (etc) work, and requires knowledge of the ircd's USERLEN setting. Unfortunately, it does not seem that USERLEN is generally reported as part of RPL_ISUPPORT..


Saturn, QuakeNet staff
Joined: Aug 2003
Posts: 319
P
Pan-dimensional mouse
OP Offline
Pan-dimensional mouse
P
Joined: Aug 2003
Posts: 319
Originally Posted By: Khaled
If I recall correctly, at one time mIRC did store more than nine characters for the user string, however due to bug reports relating to that behaviour mIRC was changed to comply with the maximum length.

I agree with this approach, but just in case it makes a difference I should say that my tests with mIRC show that it allows userids up to 10 characters.

Originally Posted By: Khaled
I can't remember the reason for the original bug report unfortunately apart from the fact that there were side-effects on some IRC networks when the maximum length was not enforced.

While I could revert this change, this will result in the same issue that users reported years ago that led to this change in the first place.

As I said, I think mIRC should enforce 9 or 10 characters on the Options/Ident page.

Originally Posted By: Khaled
$mask() was made to work this way based on input from users who were having issues with servers that could not handle long userids. Anything beyond 9 characters is chopped to nine characters and prefixed with a wildcard.

As I said, $address(nick,5) correctly handles userids of 10 characters. If I set my userid to ABCDEFGHIJ (10 characters), $address(,5) gives nick!ABCDEFGHIJ@host and $address(,6) gives nick!*BCDEFGHIJ@host.

Originally Posted By: Khaled
mIRC did follow this - it originally had no limit. However, as different server implementations used different methods, and were affected in different ways by userids longer than nine characters, there was no other way to prevent these issues.

As stated, mIRC should only allow users to set a limited length userid, but I don't see how handling longer ones in $address(,5/6) would cause an incompatibility.
Originally Posted By: Khaled
If you can provide a step by step method of reproducing this issue, so that I can see where it is being inconsistent, I will try to reproduce it here. Note that any further changes will need to chop the userid to 9 characters.

Try:

1. Set DCC Get autoaccept from trusted users.
2. Connect to irchighway, join #ebooks.
3. /whois dragnbreaker
4. //echo -a $address(dragnbreaker,5)
5. //echo -a $ial(dragnbreaker)
3. /dcc trust $address(dragnbreaker,5)
4. In #ebooks, send "!dragnbreaker Canavan, Trudi - Age of the Five 01 - Priestess of the White (v5.0).epub"

File should be auto-accepted, but it won't be.

According to ctcp VERSION, dragnbreaker is running mIRC 6.35.

IMO, $ial(nick) is correct (IAL should hold the full mask), and $address(nick,5 or 6) should be fixed to use the full userid. I don't believe that this will create any significant backward compatibilities, but will create consistency.

Creating consistency by keeping $address as-is and changing everything else is both a much bigger job and likely to lead to significant backwards compatibility.

Joined: Aug 2003
Posts: 319
P
Pan-dimensional mouse
OP Offline
Pan-dimensional mouse
P
Joined: Aug 2003
Posts: 319
Originally Posted By: Sat
Most probably the issue was ban masks. Many server implementations limit the username part of ban masks to the username length. For example: if you attempt to ban *!*1234567890@* on a server with USERLEN=10, the ircd may set the ban *!*123456789@* instead. This is why it is essential to keep enforcing the correct limit, and instead ban *!*234567890@* on such networks. That affects the way $mask (etc) work, and requires knowledge of the ircd's USERLEN setting. Unfortunately, it does not seem that USERLEN is generally reported as part of RPL_ISUPPORT..


That makes sense. Commands to the server for e.g. bans should conform to the specs. But there are several use cases:

1. Ban '*!123456789@*' - conformant should be no problems.
2. Ban '*!*123456789@*' - still conformant should be no problems.
3. Ban '*!1234567890@*' - not sure whether this is conformant or will cause problems - change to ban '*!*234567890@*'.
4. Ban '*!*1234567890@*' - non-conformant - change to ban '*!*234567890@*'.

In fact, this should apply consistently to all commands sent to the server which include a mask.

In other words, the issue is not with how we handle this at the client, but how we send commands to the server.

For the real-life example 'dragnbreaker!dragnbreake@*' we would use 'dragnbreaker!*agnbreake@*' which is what $address(dragnbreaker,6) produces.

So, $address(nick,6) is probably ok. Just $address(nick,5 / 15?) which needs fixing.


Last edited by Protopia; 19/07/17 11:20 AM.
Joined: Jan 2004
Posts: 2,127
Hoopy frood
Offline
Hoopy frood
Joined: Jan 2004
Posts: 2,127
Quote:
This is why it is essential to keep enforcing the correct limit, and instead ban *!*234567890@* on such networks.


That causes a problem related to this feature request

This mask behaves as if a 10-character Userid losing identd drops the 1 when I've always seen it dropping the 0.

Identd string: 1234567890

With Identd:
Userid 1234567890 masks as *!*234567890@*.host
Without Identd:
Userid ~123456789 masks as *!*123456789@*.host

Neither of these masks match a user in both with+without identd states. Also, even if the server doesn't allow creating ban masks of sufficient length, there still is value in being able to create the longer masks for mIRC to use internally in /guser and $ulist

I had suggested adding masks 20-29 to deal with this issue as well as preserving backwards compatibility, so perhaps masks 20-29 could instead be created to somehow deal with both the issue of 10-character Userid strings losing identd as well as the issue of longer-than-10 character userid strings.

Joined: Apr 2004
Posts: 871
Sat Offline
Hoopy frood
Offline
Hoopy frood
Joined: Apr 2004
Posts: 871
Honestly, I think that's a problem of an altogether different nature, and should be considered separately, even if there might be some overlap in possible solutions..


Saturn, QuakeNet staff
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Quote:
So, $address(nick,6) is probably ok. Just $address(nick,5 / 15?) which needs fixing.

I reviewed the source code - the address mask routine is used by $mask(), $address(), and a large number of core features, such as /auser, /ruser, /guser, /ban, /ignore, /aop, /avoice, /protect, /dns, /localinfo, and so on. It has been unchanged since at least 2003. Some of these features use $mask(,5/15) but many use variable mask types depending on the command/context.

Note that mask types 0/10 and anything beyond the range 0-19 also chop the userid to 10 characters. To apply your requested change, I would need to change the results of all of $mask(,0/5/10/15/Beyond) for consistency.

One of the difficulties with long-lived applications like mIRC is that issues are reported, fixed, tested, tweaked, stabilized and then ten years later someone reports an issue with that feature outside of the context of the original bug reports that prompted those changes. I then find myself breaking the feature for many users because it is impossible to remember the reasons for all of the tweaks that were made to stabilize it.

As the original reason the userid was chopped to 10 characters was because servers limited it to 10 characters and users reported issues with longer userids (possibly just related to ban addresses, as Sat mentioned, but perhaps there were other issues?), how will this change affect a feature/script that sends $mask() addresses with non-chopped userids to different server versions? Will some server versions not process them correctly? Also, if a feature/script has built a list of stored addresses over many years that contains $mask() addresses, how will it be affected by this change?

On the other hand, for your specific purpose, the full address can be retrieved using $ial().

Joined: Feb 2003
Posts: 2,812
Hoopy frood
Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,812
Khaled's seems like a fair assessment. >Masking< is highly contextual and limitations placed on its output seem to be within reason. Length limitations of userid masking has always been a song and dance, especially when considering tilde marking, so it'd be prudent to maintain compatibility with the most restrictive server's length implementations (on banmasks, etc).

I too was guilty of using $address($me,5) to retrieve my $fulladdress, instead of using $ial($me). Clarity in documentation may be warranted; pointing users to $ial(nickname).

I wonder if $address(nickname,5) should return nickname!*onguserid@host.name, where $ial(nickname) returns nickname!verylonguserid@host.name, or just maintain its current behavior.

I wonder if $address(nickname) should return $ial(nickname), making mask-type an optional parameter. Maybe useful for selective outputs with $address(nickname,%i) where %i can be $null or omitted.


Well. At least I won lunch.
Good philosophy, see good in bad, I like!
Joined: Aug 2003
Posts: 319
P
Pan-dimensional mouse
OP Offline
Pan-dimensional mouse
P
Joined: Aug 2003
Posts: 319
What I believe is most important is matching the address for DCC GET trust works with all the $address modes including 5.

This might mean matching against both $ial($nick) and $mode($nick,5) if they are different - I doubt that this would introduce any backward incompatibilities or security issues.

In the mean time I can switch my own code to use $ial($nick) if you can confirm that is the one which will work.

Many thanks.

P


Link Copied to Clipboard