[JDEV] servers specifying from fields

[Mathew A Johnston]

Does this mean that no problem will occur if a user does specify the
correct from attribute, and the server does not adjust it?

In this case, an encrypted <message> element, containing a to and from
attribute, encapsulated within a normal <message> element (which would
contain a server verified from address) would work out just fine. How the
from address within the encrypted <message> element would be handled is
another question. A receiver that's smart would look at the normally
transfered from address, and compare it to the one specified in the
decrypted message element - if the two are different, both messages should
be dropped.

Thoughts?

> The server will remove any specified 'from' attribute to prevent a user
> falsifying their address,
> any other server will not allow a server to send a falsified 'from' address
> (the purpose of dialback - I believe any from attribute which does not have
> the exact servername will cause the receiving server to close the
> connection).
> 
> I can set up a server and turn off the from replacing logic, and then I can
> spoof any address I want on my own server, which still gives plenty of
> accountability if I'm trying to spam people or anything else malicious
> (evident server DNS name, IP  in server logs)
> 
> -David Waite
> 
> Mathew A Johnston wrote:
> 
> > With regards to my last message:
> >
> > I've been told that the from field on messages is set by the server
> > which the client used to send the message and that this was done to help
> > prevent users from forging from addresses. It is my opinion that this
> > should never be done by the server, as it hardly reduces the chances of
> > forged messages (any user can run their own server). It also greatly
> > complicates the proposal that I just put forward about encrypting whole
> > messages to have them parsed after decryption by the receiving client. If
> > an encrypted <message> tag passes by the server, the server can not add
> > the from attribute, and if the user was not allowed to supply their own
> > from attribute, there wont be a from attribute on the received message.
> > A HACK around this would be for the decrypting client to assume the same
> > from attribute as was attatched to the encapsulating message.
> >
> > If you want to assure the integrety and source of a message, use the
> > message signing facilities provided by the jabber:x:signed namespace.
> >
> > Mathew Johnston
> >
> > _______________________________________________
> > jdev mailing list
> > jdev at jabber.org
> > http://mailman.jabber.org/listinfo/jdev
> 
> 
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev
>