Send message stanza on behalf of a user

We would like to implement a module and API which enables the user to send message via email to a JID, especially to a MUC room. The module can properly parse the incoming email and handle the user identification.

Is there a recommended way to programmatically send a message stanza to a jid via Tigase? I wonder if there is already some similar API or plugins, is RestMessageReceiver something I should look into? Or if we need to write our own plugin, do you have any recommendation?

Best of all, not sure if there is any XMPP spec or approach to deal with this send-message-on-my-behalf case...

Many thanks!

Replies (10)

There are no spec for this. But there are a few ways to do this in Tigase. The main question is how much traffic you want to handle this way. Because there are quite simple ways to do it but do not offer a high performance.

For example you can inject a packet to the Tigase on behalf of any user using administrator ad-hoc command. So basically a simple working solution could consist of a comment line mail filter script which could analyze email and then forward it to XMPP using, for example our Tigase comment line management tool. The tool can connect as an admin to Tigase and submit a message for a final delivery.

This would work without any problems but I do not think it could handle a high volume of emails to XMPP that way.

The admin ad-hoc command are based on scripting. There are scripts for many tasks already. Updating user's roster is also implemented. There is no script for sending a message, however, based on existing code it should be not very difficult to implement a new script for this task.

The inefficient part is "executing ad-hoc command through a command line tool". More specifically, I mean, if you would have to run the tool from a command line each time for each single message. Much more efficient way would be to have your "email parsing part" to run as a process with is in memory and working all the time (not started for each message) and if this part is connected to the Tigase all the time. Then sending an ad-hoc command to forward email as XMPP message is very fast.

So in other words, the whole overhead for starting a command line tool and/or connecting to XMPP server, authenticating is relatively long process, not suitable for a high number of messages.

Permanent XMPP connection between the email parsing part and Tigase would be very efficient, even much better that REST calls which is also supported by Tigase.

Permanent XMPP connection between the email parsing part and Tigase would be very efficient

This is great. I am a little curious about the logics behind the scene... Let's say the email-parser is process always running, and establishes ONE permanent XMPP connection as a special user, e.g, "admin". Is this true that the "admin" user can send messages on behalf of many "different" users? Is this logic done in tigase server code, or is it somewhere in the script? Which java class should l look into?

Our use case is very simple: we allow any users to reply to a some email address to "send" a message to a (room) chat. So will one persisted xmpp connection meet this requirement of "many" different users?

By the way, I did not find any update-roster script, only get-roster from here:

This is great. I am a little curious about the logics behind the scene... Let's say the email-parser is process always running, and establishes ONE permanent XMPP connection as a special user, e.g, "admin". Is this true that the "admin" user can send messages on behalf of many "different" users?

Yes, this is true. Admin can do anything.

Is this logic done in tigase server code, or is it somewhere in the script? Which java class should l look into?

Use them as an example. There is a command which sends a message to all online users. I think it might be a good starting point for your own ad-hoc script.

Our use case is very simple: we allow any users to reply to a some email address to "send" a message to a (room) chat. So will one persisted xmpp connection meet this requirement of "many" different users?

Yes.

By the way, I did not find any update-roster script, only get-roster from here: