mIRC Home    About    Download    Register    News    Help

Print Thread
PRIVMSG from user nick #228502 25/12/10 10:27 PM
Joined: Apr 2010
Posts: 59
A
ascription Offline OP
Babel fish
OP Offline
Babel fish
A
Joined: Apr 2010
Posts: 59
Hello,

Not sure if this is a bug or feature request.

I'm writing an interface between IRC and a network. One of its functions is an away message when I'm not signed in.

I'd like to deliver the away message to myself, but mIRC seems to be ignoring the recipient in PRIVMSG messages.

For instance, if my interface daemon sends:

:nick111 PRIVMSG nick222 :message

Then it appears in a window from nick111, not the existing window between me and nick222.

Furthermore, the "nick222" parameter seems to be disregarded altogether.

Thanks and sincerely,
ascription

Re: PRIVMSG from user nick [Re: ascription] #228532 27/12/10 02:54 AM
Joined: Aug 2004
Posts: 7,252
R
RusselB Offline
Hoopy frood
Offline
Hoopy frood
R
Joined: Aug 2004
Posts: 7,252
Some networks require you to use the /raw command along with the appropriate parameters for things like prvmsg.

By using mIRC, you can ignore that (possible) problem by simply using the /msg command.

Not being familiar with privmsg I can't state that you're doing anything wrong. If you decide to use mIRC /msg command, then you can specify multiple recipients by separating them with a comma.

I can look up more details regarding /raw and prvmsg (and other commands) in about an hour, as I'm on a train right now and don't have the references with me.

Re: PRIVMSG from user nick [Re: ascription] #228535 27/12/10 03:03 AM
Joined: Oct 2004
Posts: 8,330
Riamus2 Offline
Hoopy frood
Offline
Hoopy frood
Joined: Oct 2004
Posts: 8,330
If you want to verify that you're using the correct format for the commands, type this in mIRC:

/debug @debug

That will enable a debug window. Now, send a message to someone. You can then look in that debug window to see the format you should be using for PRIVMSG.


Invision Support
#Invision on irc.irchighway.net
Re: PRIVMSG from user nick [Re: ascription] #228539 27/12/10 07:00 AM
Joined: Feb 2006
Posts: 546
J
jaytea Offline
Fjord artisan
Offline
Fjord artisan
J
Joined: Feb 2006
Posts: 546
if the server sends ":nick PRIVMSG target :msg" and the target is not a channel, mIRC interprets this as a private message from 'nick'. so, you're quite right, mIRC will appear to ignore 'nick222' - or, at least, pretend that the message was directed at you.

a well constructed IRC server should not be sending you PRIVMSGs intended for other clients (ie. the target should either be a channel or your own nickname: $me), so mIRC's behaviour does not seem unreasonable. how else do you propose mIRC handle such an event?

the actual target of the PRIVMSG is available to scripters in events such as on TEXT through the $target identifier.


"The only excuse for making a useless script is that one admires it intensely" - Oscar Wilde
Re: PRIVMSG from user nick [Re: jaytea] #228547 27/12/10 07:06 PM
Joined: Apr 2010
Posts: 59
A
ascription Offline OP
Babel fish
OP Offline
Babel fish
A
Joined: Apr 2010
Posts: 59
Originally Posted By: jaytea
a well constructed IRC server should not be sending you PRIVMSGs intended for other clients (ie. the target should either be a channel or your own nickname: $me), so mIRC's behaviour does not seem unreasonable.


Colloquially, I'm sending a message to the network that I didn't know about. So I want to inform mIRC of that fact.

My interface program, a "middle man" program, sends:

PRIVMSG nick222 :message

to the network. It also sends:

:nick111 PRIVMSG nick222 :message

to the program I'm connecting with, the non-network end, mIRC. I advance mIRC should display "<nick111> message" in the query window with nick222.

There is a security issue, that you might not notice a MITM attack, since the forged message will be not just absent but displayed as authentic.

I noticed the anomaly isn't present in messages to a channel, only individuals. Forged messages to a channel are displayed correctly as from the user's nick.

If mIRC can accomplish this with a script, such as on TEXT as you suggested, it would be satisfactory. I hadn't pursued it at time of writing.

The logic would be something like this:

Code:
On receiving PRIVMSG {
  If recipient is a channel {
    ... normal logic ...
  } Else {
    If sender == self {
      display in (new) query window with recipient:
        <self> message
    } Else If recipient == self {
      display in (new) query window with sender:
        <sender> message
    } else {
      disregard.
    }
  }
}

I observed that PRIVMSGs to channels to which there is no window open are correctly discarded. The "corner case" of that situation is that QUIT messages from users who are not in any channels to which there *is* an open window, are routed to the Status window. According to the above logic, they would be discarded as well, which I moderately agree with but not strongly.

Thanks sincerely.

Re: PRIVMSG from user nick [Re: ascription] #228561 30/12/10 04:00 AM
Joined: Apr 2010
Posts: 59
A
ascription Offline OP
Babel fish
OP Offline
Babel fish
A
Joined: Apr 2010
Posts: 59
If I understand correctly, this sort of behavior for the program would be perceived as against the rules. I'd like to argue that it's not against them; rather, they are silent on the matter. That is, it's not specified one way or the other what a client program should do in this case. Therefore, it's not so much against the rules, as outside them.

I don't know mIRC well enough to know if there are any features it supports that aren't official IRC behaviors. Are there? If so, what? If not, why not?

Furthermore, regardless of the letter of the official IRC spec., I think the proposed modification is consistent with the spirit of it. Script-making already interferes with the "raw text" of IRC, and presumably most (or all) of what my MITM program does mIRC could do in scripts.

I think the basic image I'd like to portray is "client chaining", which may not necessarily be precedented. Clients needn't demand to be connected directly to the source network. Instead, they could permit chains as the user sees fit. It may be a matter of permitting them or denying them as a class entirely, to recognize messages that are from the user's nick.

Is this a matter for the Feature Suggestions forum?

Thanks and sincerely.