Re: [Standards] Jabber Components (XEP-0114) & TLS
On 2 April 2014 20:12, Peter Waher wrote: > Hello > > I have some questions regarding the Jabber Components protocol. Couldn't > find anything about it in the XEP. It would be great if somebody with some > insight could answer: > > 1) Regarding TLS: > 1a) How is starttls used together with the component protocol and stream > initiation? > 1b) When? Before or after the handshake? > > Components are a "XMPP/0.9" protocol, in as much as they lack stream features. I think some servers will provide you stream features, including TLS, if you give a version number (but that's beyond what XEP-0114 discusses). Typically, they're deployed across loopback, so TLS is of limited use. > 2) Regarding port number: > 2a) Is there a default port for this protocol? Is it the same as > client-to-server communication? Or another? > 2b) OpenFire seems to use 5275, is this common? > > There is no default port. Some servers use a distinct port, others use S2S (or C2S, or both). > 3) How about other stream initiation elements, like: > 3a) features? > Features are not discussed by XEP-0114 at all; see above. > 3b) sessions? > > No, there's no sessions. There aren't, really, in anything. > XEP-0114 just terminates after the handshake element. > Think of XEP-0114 as a sort of relaying, simplified, S2S. > > Best regards, > Peter Waher >
Re: [Standards] Jabber Components (XEP-0114) in federated networks
On 2 April 2014 20:25, Peter Waher wrote: > Hello > > I have some more questions regarding the Jabber Components protocol: > > 4) Regarding Federation, can clients on one server access components > hosted on another? For example: Can client@server1 communicate with > component.server2 ? > > Yes; the components are externally just another S2S domain. > 5) Can a client on one server discover components on another to which it > is not connected, but with which the first server is federated? > > Yes, the components are externally just another S2S domain. > Best regards, > Peter Waher >
[Standards] Jabber Components (XEP-0114) in federated networks
Hello I have some more questions regarding the Jabber Components protocol: 4) Regarding Federation, can clients on one server access components hosted on another? For example: Can client@server1 communicate with component.server2 ? 5) Can a client on one server discover components on another to which it is not connected, but with which the first server is federated? Best regards, Peter Waher
[Standards] Jabber Components (XEP-0114) & TLS
Hello I have some questions regarding the Jabber Components protocol. Couldn't find anything about it in the XEP. It would be great if somebody with some insight could answer: 1) Regarding TLS: 1a) How is starttls used together with the component protocol and stream initiation? 1b) When? Before or after the handshake? 2) Regarding port number: 2a) Is there a default port for this protocol? Is it the same as client-to-server communication? Or another? 2b) OpenFire seems to use 5275, is this common? 3) How about other stream initiation elements, like: 3a) features? 3b) sessions? XEP-0114 just terminates after the handshake element. Best regards, Peter Waher
Re: [Standards] deprecating in-band registration
Hello Kevin Thanks for your input. >> Hello Peter & community >> >> As I mentioned before, I have an idea on how to make IBR secure. It would >> work as follows: >> >> * A manufacturer, or responsible party, would create an account on the xmpp >> server, or have an account created for him by an operator. There he/she >> could be allowed to create a certain number of accounts automatically. >> * The manufacturer would get a shared secret (say an "API Key") identifying >> the account. >> * Each device or application wanting to perform IBR would have this key >> configured. >> * When the device or app connects to the server, using IBR, it returns a >> registration form, as specified in IBR. But one (or two) of the fields would >> contain a challenge. >> * The device or application fills in the response field according to the >> shared secret and the challenge. Perhaps using OAUTH. >> * When registering, the new account would be discounted from the pool of >> accounts permitted by the key. >> * If a shared secret gets to be known, the manufacturer or responsible party >> can just choose to generate a new shared secret (or key). >> >> In this way operatos of the xmpp server can have control of who are trusted >> to create accounts automatically. And they in turn have control of how many >> accounts can be created, and monitor how many have been created. And it >> allows them to create devices without preprogrammed JID:s. >> >> What do you think about such an approach? > >If you're at the stage of putting shared secrets into the devices, why not >generate certs for the devices, and do auto-provisioning of accounts based on >the certs provided by clients? This doesn't require new protocol and allows >fine-grained control. Actually, I've left the nature of the shared secret open at this point to be able to have a discussion. I've myself been a proponent for many years of using certificates in assuring communication, but with very poor results to be honest. It has been very difficult for me to convince product manufacturers why they should use certificates, even when it has been possible. The problem with certificates is basically: They are costly (either you have to buy them, or set up a certificate server) and limited in time. A manufactured product like a sensor or meter must have a life span of 10 years. Where do you get a valid certificate valid for 10 years, without self-signing one and manually installing it in the certificate registry (something you shouldn't do)? Using certificates to install system components, especially server components is easier to motivate, or to identify public domains even easier. This trend for a simpler method for authentication than using certificates is visible also in API design and mobile app development (paralleling the work to simplify web service requests, where developers prefer REST before SOAP). OAUTH [1] has become a very popular choice, and is one which I personally am leaning on would make a good candidate. It much easier for a non-initiated to become started, and it's easy for a production environment, and it is sufficiently secure and reliable. There's an IETF draft for a SASL extension to OAUTH [2] and large web API operators like Google support it [3]. It is also completely free and easy to automate in a production environment (or on a Web API page). An XMPP Server can easily produce new valid OAUTH keys by itself. [1] http://oauth.net/ [2] http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-14 [3] https://developers.google.com/accounts/docs/OAuth2 Actually, Google models their API accounts in a similar way to the one proposed above. There, an account holder is given a certain number of API calls per time unit, which it can then distribute among its users. The above method would do something similar: An account holder would be given a certain number of accounts that can be created, and can distribute this right to its users (Thing). Best regards, Peter Waher
Re: [Standards] Proposed XMPP Extension: Internet of Things - Discovery
On 02/04/14 16:14, Peter Waher wrote: > Hello Philipp > > Thanks for your insightful input. My response to the main item: > section 3.4: I don't think IBR should be recommended anymore. >>> IoT requires automatic account creation. However, I agree it must also be >>> secure, from the point of view of the server administrator, especially if >>> servers are publically available. I will post a separate XEP soon, that >>> provides a secure in-band registration mechanism that can be used by things. >>> section 3.5: I would recommend moving the discovery to standard disco#items and to use components (xep-0114) -- those are not much harder to write than standard clients and have many advantages in terms of managability. >>> Note sure here how this relates to 3.5. Was it a particular step you >>> referred to? >> Basically I'd like to see the method #3 in 3.5 as the one and only way to do >> it, with examples. Basically a slightly expanded version of the "determining >> support" section: >> disco#items to the server >> then disco#info to each item to look for something which has a >> urn:xmpp:iot:discovery. >> >> xep-0114 style components are just a very convenient way to do this in most >> server implementation, but I assumed that you had implemented this using a >> registry which was running over c2s. So I mixed up implementation comments >> and protocol comments :-/ >> >> I don't have a strong opinion whether that should be done before accepting >> it or afterwards. Might be handy to pretend the other methods never existed. > Ok. I will certainly have a look at the Jabber Components Protocol > (XEP-0114). Even though it is historical, it looks promising. Is there any > more recent information available than > http://xmpp.org/extensions/xep-0114.html? > > One of the mayor problems is that in IoT architecture, we can in many cases > not choose the XMPP server. In some cases we do, but not in the most > important cases where for instance large operators or companies already have > their XMPP server chosen (their own in many cases). Since the XMPP server has > already been chosen by the operator in these cases, we need a solution that > can work regardless of XMPP server used. > > This does not mean XEP-0114 is not a good idea to use, especially if > available. The problem is, this cannot be guaranteed. I will most certainly > explore this. However, is it possible that we do this during experimental > phase? This gives me some time to investigate how widespread the support for > XEP-0114 in the XMPP servers chosen for us is. It will also give us some > feedback if this can be said to be the main option, or a supplementary option > to use. You seem to confuse Historical with Deprecated. Although the XEP is historical, the status is active. Furthermore, all servers I have used so far support XEP-0114: this is a core feature of most implementations. Edwin
Re: [Standards] Proposed XMPP Extension: Internet of Things - Discovery
Hi Peter et. al. Just a quick one about XE-0114 (external components): Most xmpp developers are putting their business logic there and its dead simple and every server out there supports it. + since its a protocol and can be run as client or server it makes it very portable and robust. :-) /Steffen On 02 Apr 2014, at 16:14, Peter Waher wrote: > Hello Philipp > > Thanks for your insightful input. My response to the main item: > section 3.4: I don't think IBR should be recommended anymore. >>> >>> IoT requires automatic account creation. However, I agree it must also be >>> secure, from the point of view of the server administrator, especially if >>> servers are publically available. I will post a separate XEP soon, that >>> provides a secure in-band registration mechanism that can be used by things. >>> section 3.5: I would recommend moving the discovery to standard disco#items and to use components (xep-0114) -- those are not much harder to write than standard clients and have many advantages in terms of managability. >>> >>> Note sure here how this relates to 3.5. Was it a particular step you >>> referred to? >> >> Basically I'd like to see the method #3 in 3.5 as the one and only way to do >> it, with examples. Basically a slightly expanded version of the "determining >> support" section: >> disco#items to the server >> then disco#info to each item to look for something which has a >> urn:xmpp:iot:discovery. >> >> xep-0114 style components are just a very convenient way to do this in most >> server implementation, but I assumed that you had implemented this using a >> registry which was running over c2s. So I mixed up implementation comments >> and protocol comments :-/ >> >> I don't have a strong opinion whether that should be done before accepting >> it or afterwards. Might be handy to pretend the other methods never existed. > > Ok. I will certainly have a look at the Jabber Components Protocol > (XEP-0114). Even though it is historical, it looks promising. Is there any > more recent information available than > http://xmpp.org/extensions/xep-0114.html? > > One of the mayor problems is that in IoT architecture, we can in many cases > not choose the XMPP server. In some cases we do, but not in the most > important cases where for instance large operators or companies already have > their XMPP server chosen (their own in many cases). Since the XMPP server has > already been chosen by the operator in these cases, we need a solution that > can work regardless of XMPP server used. > > This does not mean XEP-0114 is not a good idea to use, especially if > available. The problem is, this cannot be guaranteed. I will most certainly > explore this. However, is it possible that we do this during experimental > phase? This gives me some time to investigate how widespread the support for > XEP-0114 in the XMPP servers chosen for us is. It will also give us some > feedback if this can be said to be the main option, or a supplementary option > to use. > > Ok? > > Another concern is the following description in the introduction: "While this > component protocol is minimal and will probably be superseded by a more > comprehensive component protocol at some point". > > Do you know anything about such plans for a future more comprehensive > component protocol? > > Best regards, > Peter Waher > smime.p7s Description: S/MIME cryptographic signature
Re: [Standards] Proposed XMPP Extension: Internet of Things - Discovery
Hello Lance Thanks for taking the time to read the proposal and your input. My responses to your concerns below: >> Example: Consider 100'000 devices connecting to an XMPP server they've found >> somehow, and then need to find a Thing Registry to register themselves. One >> might be preconfigured, but I want to include the case when one is not. >> 100'000 devices cannot start looping through all possible JIDs and ask >> service discovery to find out who can what. So it needs, as a last attempt, >> to try to find it somehow. How do you suggest this done, if you do not >> accept the methods proposed (as the last resource)? > >The approach we would suggest is that the Thing Registry be implemented as a >server component (and thanks to XEP-0114 can be used with any XMPP server that >supports XEP-0114, which is to say all of them). A Thing would then iterate >over the items in a disco#items result for the XMPP server, looking for one >that provides the registry feature. The disco#items result for a server is on >the order of tens, not hundreds of thousands. For example, that process is how >a user discovers SOCKS5 proxies for file transfers. > >Implementing a service like the IoT Thing Registry using a client connection >is, from our collective experience as XMPP devs, ill advised even though it is >technically possible. Note that several sections of the proposed XEP exist >solely to work around issues from using a client connection (presence >subscriptions and limitations with roster sizes) that a server component does >not need to deal with. As I responded to Philipp, XEP-0114 looks promising. I take the liberty to copy the response to the same argument: Ok. I will certainly have a look at the Jabber Components Protocol (XEP-0114). Even though it is historical, it looks promising. Is there any more recent information available than http://xmpp.org/extensions/xep-0114.html? One of the mayor problems is that in IoT architecture, we can in many cases not choose the XMPP server. In some cases we do, but not in the most important cases where for instance large operators or companies already have their XMPP server chosen (their own in many cases). Since the XMPP server has already been chosen by the operator in these cases, we need a solution that can work regardless of XMPP server used. This does not mean XEP-0114 is not a good idea to use, especially if available. The problem is, this cannot be guaranteed. I will most certainly explore this. However, is it possible that we do this during experimental phase? This gives me some time to investigate how widespread the support for XEP-0114 in the XMPP servers chosen for us is. It will also give us some feedback if this can be said to be the main option, or a supplementary option to use. Ok? Another concern is the following description in the introduction: "While this component protocol is minimal and will probably be superseded by a more comprehensive component protocol at some point". Do you know anything about such plans for a future more comprehensive component protocol? >>However, in terms of re-using existing protocol building blocks, you should >>look into XEP-0077 some more. People seem to overlook that XEP-0077 is not >>just IBR for new XMPP account provisioning, but also a protocol letting an >>existing JID register with an arbitrary service, and then later update or >>remove that registration. Even the cases where you need additional >>information (such as when Concentrators are used) can be handled using >>XEP-0077 if that extra data can be expressed via data forms. > >Implementing some new service as a component, and letting users (which in this >case would be Things) opt-in for that service using XEP-0077 is a common >historical pattern. Not sure exactly what you mean here. In what sense do you see XEP-0077 to be used in this proposal, apart from IBR? Best regards, Peter Waher
Re: [Standards] Proposed XMPP Extension: Internet of Things - Discovery
Hello Philipp Thanks for your insightful input. My response to the main item: >>> section 3.4: >>> I don't think IBR should be recommended anymore. >> >> IoT requires automatic account creation. However, I agree it must also be >> secure, from the point of view of the server administrator, especially if >> servers are publically available. I will post a separate XEP soon, that >> provides a secure in-band registration mechanism that can be used by things. >> >>> section 3.5: >>> I would recommend moving the discovery to standard disco#items and to use >>> components (xep-0114) -- those are not much harder to write than standard >>> clients and have many advantages in terms of managability. >> >> Note sure here how this relates to 3.5. Was it a particular step you >> referred to? > > Basically I'd like to see the method #3 in 3.5 as the one and only way to do > it, with examples. Basically a slightly expanded version of the "determining > support" section: > disco#items to the server > then disco#info to each item to look for something which has a > urn:xmpp:iot:discovery. > >xep-0114 style components are just a very convenient way to do this in most >server implementation, but I assumed that you had implemented this using a >registry which was running over c2s. So I mixed up implementation comments and >protocol comments :-/ > >I don't have a strong opinion whether that should be done before accepting it >or afterwards. Might be handy to pretend the other methods never existed. Ok. I will certainly have a look at the Jabber Components Protocol (XEP-0114). Even though it is historical, it looks promising. Is there any more recent information available than http://xmpp.org/extensions/xep-0114.html? One of the mayor problems is that in IoT architecture, we can in many cases not choose the XMPP server. In some cases we do, but not in the most important cases where for instance large operators or companies already have their XMPP server chosen (their own in many cases). Since the XMPP server has already been chosen by the operator in these cases, we need a solution that can work regardless of XMPP server used. This does not mean XEP-0114 is not a good idea to use, especially if available. The problem is, this cannot be guaranteed. I will most certainly explore this. However, is it possible that we do this during experimental phase? This gives me some time to investigate how widespread the support for XEP-0114 in the XMPP servers chosen for us is. It will also give us some feedback if this can be said to be the main option, or a supplementary option to use. Ok? Another concern is the following description in the introduction: "While this component protocol is minimal and will probably be superseded by a more comprehensive component protocol at some point". Do you know anything about such plans for a future more comprehensive component protocol? Best regards, Peter Waher
Re: [Standards] deprecating in-band registration
+1 /Steffen On 02 Apr 2014, at 15:51, Kevin Smith wrote: > On Wed, Apr 2, 2014 at 2:35 PM, Peter Waher wrote: >> Hello Peter & community >> >> As I mentioned before, I have an idea on how to make IBR secure. It would >> work as follows: >> >> * A manufacturer, or responsible party, would create an account on the xmpp >> server, or have an account created for him by an operator. There he/she >> could be allowed to create a certain number of accounts automatically. >> * The manufacturer would get a shared secret (say an "API Key") identifying >> the account. >> * Each device or application wanting to perform IBR would have this key >> configured. >> * When the device or app connects to the server, using IBR, it returns a >> registration form, as specified in IBR. But one (or two) of the fields would >> contain a challenge. >> * The device or application fills in the response field according to the >> shared secret and the challenge. Perhaps using OAUTH. >> * When registering, the new account would be discounted from the pool of >> accounts permitted by the key. >> * If a shared secret gets to be known, the manufacturer or responsible party >> can just choose to generate a new shared secret (or key). >> >> In this way operatos of the xmpp server can have control of who are trusted >> to create accounts automatically. And they in turn have control of how many >> accounts can be created, and monitor how many have been created. And it >> allows them to create devices without preprogrammed JID:s. >> >> What do you think about such an approach? > > If you're at the stage of putting shared secrets into the devices, why > not generate certs for the devices, and do auto-provisioning of > accounts based on the certs provided by clients? This doesn't require > new protocol and allows fine-grained control. > > /K smime.p7s Description: S/MIME cryptographic signature
Re: [Standards] deprecating in-band registration
On Wed, Apr 2, 2014 at 2:35 PM, Peter Waher wrote: > Hello Peter & community > > As I mentioned before, I have an idea on how to make IBR secure. It would > work as follows: > > * A manufacturer, or responsible party, would create an account on the xmpp > server, or have an account created for him by an operator. There he/she could > be allowed to create a certain number of accounts automatically. > * The manufacturer would get a shared secret (say an "API Key") identifying > the account. > * Each device or application wanting to perform IBR would have this key > configured. > * When the device or app connects to the server, using IBR, it returns a > registration form, as specified in IBR. But one (or two) of the fields would > contain a challenge. > * The device or application fills in the response field according to the > shared secret and the challenge. Perhaps using OAUTH. > * When registering, the new account would be discounted from the pool of > accounts permitted by the key. > * If a shared secret gets to be known, the manufacturer or responsible party > can just choose to generate a new shared secret (or key). > > In this way operatos of the xmpp server can have control of who are trusted > to create accounts automatically. And they in turn have control of how many > accounts can be created, and monitor how many have been created. And it > allows them to create devices without preprogrammed JID:s. > > What do you think about such an approach? If you're at the stage of putting shared secrets into the devices, why not generate certs for the devices, and do auto-provisioning of accounts based on the certs provided by clients? This doesn't require new protocol and allows fine-grained control. /K
Re: [Standards] deprecating in-band registration
Hello Peter & community As I mentioned before, I have an idea on how to make IBR secure. It would work as follows: * A manufacturer, or responsible party, would create an account on the xmpp server, or have an account created for him by an operator. There he/she could be allowed to create a certain number of accounts automatically. * The manufacturer would get a shared secret (say an "API Key") identifying the account. * Each device or application wanting to perform IBR would have this key configured. * When the device or app connects to the server, using IBR, it returns a registration form, as specified in IBR. But one (or two) of the fields would contain a challenge. * The device or application fills in the response field according to the shared secret and the challenge. Perhaps using OAUTH. * When registering, the new account would be discounted from the pool of accounts permitted by the key. * If a shared secret gets to be known, the manufacturer or responsible party can just choose to generate a new shared secret (or key). In this way operatos of the xmpp server can have control of who are trusted to create accounts automatically. And they in turn have control of how many accounts can be created, and monitor how many have been created. And it allows them to create devices without preprogrammed JID:s. What do you think about such an approach? Best regards, Peter Waher -Original Message- From: Peter Saint-Andre [mailto:stpe...@stpeter.im] Sent: den 2 april 2014 00:02 To: XMPP Standards Subject: [Standards] deprecating in-band registration Several folks have commented on in-band registration (IBR, XEP-0077) recently, wondering aloud whether we really want to recommend it for things like registering devices in IoT environments. I agree with the concerns that people have expressed. I suggest that we push this line of thinking to its logical conclusion and strongly consider deprecating and then obsoleting IBR. Perhaps - perhaps! - IBR was appropriate in 1999 when we were trying to encourage people to easily try out this new technology called Jabber. Those days are long gone. If we feel that we'd like to have some kind of method for account provisioning over XMPP - and I'm not convinced that we do - then I feel that we need to rethink the whole problem, not reuse something that is fundamentally flawed. Peter
Re: [Standards] deprecating in-band registration
IBR is very useful. But many people expose it to the open world where it's open to abuse. IMHO, IBR is very useful when you are using a service like xmpp-ftw and need a way to create new users. In this situation IBR is only exposed on localhost and the web-bits, to the outside world. S. On 2 April 2014 09:36, Tomasz Sterna wrote: > Dnia 2014-04-01, wto o godzinie 21:01 -0600, Peter Saint-Andre pisze: > > I suggest that we push this line of thinking to its logical conclusion > > and strongly consider deprecating and then obsoleting IBR. [...] > > If we feel that we'd like to have some kind of method for account > > provisioning over XMPP - and I'm not convinced that we do - then I > > feel that we need to rethink the whole problem, [...] > > We have this notion of obsoleting existing protocols without providing > alternatives. > People do not like this approach and I've been defending XMPP over the > years, but to this, I have no answer. > Hell... I don't like this approach. > > IMO the correct order is: > 1. Do we want to obsolete IBB or maybe fix its issues? > 2. If we want to obsolete, we need to design its replacement. >It's easy now, since we identified its deficiencies in 1. > 3. Propose replacement for IBB and test-drive it. > 4. Obsolete IBB. > > > -- > Tomasz Sterna @ http://abadcafe.pl/ @ http://www.xiaoka.com/ > > -- Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours: goo.gl/tQgxP
Re: [Standards] deprecating in-band registration
Dnia 2014-04-01, wto o godzinie 21:01 -0600, Peter Saint-Andre pisze: > I suggest that we push this line of thinking to its logical conclusion > and strongly consider deprecating and then obsoleting IBR. [...] > If we feel that we'd like to have some kind of method for account > provisioning over XMPP - and I'm not convinced that we do - then I > feel that we need to rethink the whole problem, [...] We have this notion of obsoleting existing protocols without providing alternatives. People do not like this approach and I've been defending XMPP over the years, but to this, I have no answer. Hell... I don't like this approach. IMO the correct order is: 1. Do we want to obsolete IBB or maybe fix its issues? 2. If we want to obsolete, we need to design its replacement. It's easy now, since we identified its deficiencies in 1. 3. Propose replacement for IBB and test-drive it. 4. Obsolete IBB. -- Tomasz Sterna @ http://abadcafe.pl/ @ http://www.xiaoka.com/
Re: [Standards] Proposed XMPP Extension: Internet of Things - Discovery
> Example: Consider 100'000 devices connecting to an XMPP server they've found > somehow, and then need to find a Thing Registry to register themselves. One > might be preconfigured, but I want to include the case when one is not. > 100'000 devices cannot start looping through all possible JIDs and ask > service discovery to find out who can what. So it needs, as a last attempt, > to try to find it somehow. How do you suggest this done, if you do not accept > the methods proposed (as the last resource)? The approach we would suggest is that the Thing Registry be implemented as a server component (and thanks to XEP-0114 can be used with any XMPP server that supports XEP-0114, which is to say all of them). A Thing would then iterate over the items in a disco#items result for the XMPP server, looking for one that provides the registry feature. The disco#items result for a server is on the order of tens, not hundreds of thousands. For example, that process is how a user discovers SOCKS5 proxies for file transfers. Implementing a service like the IoT Thing Registry using a client connection is, from our collective experience as XMPP devs, ill advised even though it is technically possible. Note that several sections of the proposed XEP exist solely to work around issues from using a client connection (presence subscriptions and limitations with roster sizes) that a server component does not need to deal with. > XEP-0055 has several shortcomings when it comes to the search function we've > proposed. This is why we did not used it. Agreed that XEP-0055 does not meet the needs for this case. However, in terms of re-using existing protocol building blocks, you should look into XEP-0077 some more. People seem to overlook that XEP-0077 is not just IBR for new XMPP account provisioning, but also a protocol letting an existing JID register with an arbitrary service, and then later update or remove that registration. Even the cases where you need additional information (such as when Concentrators are used) can be handled using XEP-0077 if that extra data can be expressed via data forms. Implementing some new service as a component, and letting users (which in this case would be Things) opt-in for that service using XEP-0077 is a common historical pattern. — Lance signature.asc Description: Message signed with OpenPGP using GPGMail
