Surveiller ce forum | 
Commencer une nouvelle discussion
| RE: XSMTP [ Répondre ] Par : laurent cailleux on 2007-08-02 11:08 | [forum:52864] |
|
George, andrew, There is no reference in english. I am writing the next version and i hope it will be approved at the end of october. Just after this approval, an english version will be published. The next version will include more informations about existing headers, new headers, security and interoperability aspects. At the beginning, XSMTP was design for client side, but it is possible to use some headers for server side (like primary-precedence) to add services, improving messages handling . It is also possible to use several headers in a GW (between XSMTP and MMHS or MIP/MTIDP). Laurent. |
|
| RE: XSMTP [ Répondre ] Par : George J. Capnias on 2007-07-28 10:32 | [forum:52860] |
|
It would be nice to have the recommendation translated to English, although the implementation is not for server side products. It is more for client products, SMTP clients that would like to support xSMTP. George J. |
|
| RE: XSMTP [ Répondre ] Par : Andrew Oliver on 2007-07-27 20:51 | [forum:52859] |
|
I've done my best to read the XSMTP document via google translation: http://www.google.com/translate?u=http%3A%2F%2F64.233.169.104%2Fsearch%3Fq%3Dcache%3AmKrZSA9I26cJ%3Awww.milimail.org%2Fmilimail%2Fdocuments%2FRecommandation_format_XSMTP_V11.pdf%2B%2522Format%2BXSMTP%2522%2Bv1.1%2Brecommendation%26hl%3Den%26ct%3Dclnk%26cd%3D2%26gl%3Dus&langpair=fr%7Cen&hl=en&ie=UTF8 Unfortunately, French isn't one of the languages I speak so my comprehension of the recommendations are a bit weak. Are there other references? Is there a reference implementation (code) for this? I'd be interested in implementing it in Meldware's open source mail server (http://buni.org). |
|
| RE: XSMTP [ Répondre ] Par : laurent cailleux on 2007-07-13 13:51 | [forum:52819] |
|
Graeme, I understand IETF position about priority issue. But the first scope of XSMTP is military and administration environments. In this case, it is possible to implement priority mecanisms on dedicated networks. IMHO, there are differents solutions to implement priority in SMTP systems. The first solution is to extended SMTP protocol (2821). We have implemented a solution based on Schmeing's draft on our testbed. The main problem with the kind of solution is all SMTP servers must implement this extension. If one server doesn't implement this extension, the priority is not relayed. It is also possible to use the primary and copy precedence (XSMTP) field to relay priority without risk. In this case, primary and copy precedence informations can't be lost. The main goal of XSMTP is to be a generic format for military CIS based on SMTP. The second objective is to use XSMTP in mixer gateway with extensions. I think the next version (XIMF) will not include PLQ header and we will just use primary and copy precedence headers to match with STANAG (throught specific mixer gateway). I'm aware of the MTIDP Format and we can use this format with specifics connectors. I'm still working on the redaction of the next version of XIMF. I hope to finish this redaction as soon as possible. Laurent |
|
| RE: XSMTP [ Répondre ] Par : Graeme Lunt on 2007-07-01 09:07 | [forum:52775] |
|
Laurent, Thanks for the background information. How have you extended SMTP? I tried to add a priority field but the IETF thought it would just be abused in the Internet environment (which it probably would!). In a more formal environment it may be more useful. See: http://sunsite.mff.cuni.cz/MIRRORS/ftp.ripe.net/internet-drafts/draft-onions-priority-smtpext-00.txt I think if XSMTP aims to carry the same elements of service as P772 then interoperability needs to be designed in from the beginning - it shouldn't really come in a second phase. As far as PLQ and Extended Grade of Delivery go, you would take the "Priority:" field from MIXER - this the "Grade of Delivery" - and then use the new PLQ field from SMTP to augment this field to give you an "Extended Grade of Delivery". I think it is worth keeping the PLQ field, especially in the absence of any direct SMTP support. For Security Classification, I agree that a string representation should be present - I was just saying that an integer value should always be present. This again allows mapping into a P1 and/or P772 label. S4406 Ed1 defines the Information Security Label heading field which actually includes many security labels (content, heading, bodyparts). As you only have one classification field, your document should make clear which label the classification relates to. And whilst the ISL is deprecated in S4406 Ed2, I think it may well continue to be used when messages are not signed. Are you aware of the MIP IMF Extensions: http://www.mip-site.org/publicsite/03-Baseline_2.0/MTIDP-MIP_Technical_Interface_Design_Plan/ANNEX%20B%20-%20MIP%20ESMTP%20Specification/MTIDP-AnnexB-MIP_ESMTP_Specification-DNK-SEAWG-2.6.PDF They also define (poorly IMHO) extensions for precedence, classification, DTG and SICS. However they are fairly well established. It may be worth at least discussing these within a new version of your document. Graeme |
|
| RE: XSMTP [ Répondre ] Par : laurent cailleux on 2007-06-22 13:51 | [forum:52760] |
|
I'm sorry for the delay but i travelled last weeks. 1) A minor point I know, but why does the document call itself XSMTP. It defines IMF extensions, not SMTP extensions, so why not call it XIMF? (I am similiarly irritated by STANAG 4406 calling signed P772 content "S/MIME" - it is not S/MIME! The document you read is a part of a standard including transport and format. But, I agree with your remark. This part of XSMTP is based on RFC 2822 (IMF) 2) The document does not refer to MIXER (RFC 2516) which it really needs to for two reasons: a) P772 is based upon P22 so the document needs to describe how the base P22 fields should be encoded. b) It would be beneficial if XSMTP could be able to be mapped to/from a X.400 P772 message at an appropriate gateway. The main goal of XSMTP format is to be a generic format for CIS (and for french CIS at the beginning). But, i also agree with you and the second goal of XSMTP format is to extend interoperability with P772 system. XSMTP format is implemented in gateway compliant with mixer protocol. 3) XSMTP Headings Extensions There are a number of confusions in the text. For example: * Priority Level Qualifier and Extended Grade of Delivery are in fact the same Element of Service in S4406. At the beginning, Priority Level Qualifier and Extended Grade of Delivery were defined in XSMTP if someone needs it. I think the gateway will match XSMTP Primary-Precedence to P772 (P22) Priority Level Qualifier and Extended Grade of Delivery. And for the next version of XSMTP, maybe these two extensions will disapear. * The BNF for multi-valued fields is wrong and actually only allow 1 or 2 values (e.g. Distribution-Codes) Modification in new version. * Some fields are defined as single-valued, when in fact they should be multi-valued (e.g. Message-Instructions) Modification in new version. * Security-Classification must have a numeric value associated with the string form (like Primary-Precedence) If MUA (without extension) is not able to match Security-Classification, user can read the security classification. It is to be human readable. * It is unclear which field Security-Classification refers to (my assumption is Content-Security-Label) It is just to have information of email classification if you do not use SMIME. 4) It is unclear which version/edition of S4406 XSMTP is based upon. XSMTP is based upon S4406 Ed.1 V3. The next version will be problably based upon Ed.2. But, the main goal of XSMTP format is to be a generic format for CIS As it stands at the moment, I don't think that Format XSMTP is sufficiently well-defined to implement in MiliMail, and would benefit from a thorough review. FYI, i am writing a next version of XSMTP, XIMF ;-), with differents aspects as security. And yours remarks are very interesting for this work. Laurent |
|
| XSMTP [ Répondre ] Par : Graeme Lunt on 2007-06-02 19:07 | [forum:52717] |
|
Hi, I have read the "Format XSMTP" v1.1 recommendation with interest having looked at this area in the past. In October 93, I co-wrote a draft RFC (draft-onions-x400p772-822-mapping) which was submitted to the IETF but, not surprisingly, they did not want to progress it. It was however implemented in the Nexor gateway products. Anyway, a couple of comments on XSMTP. (My French comprehension is not that good so please excuse me if any of these points are actually covered in the document). 1) A minor point I know, but why does the document call itself XSMTP. It defines IMF extensions, not SMTP extensions, so why not call it XIMF? (I am similiarly irritated by STANAG 4406 calling signed P772 content "S/MIME" - it is not S/MIME! 2) The document does not refer to MIXER (RFC 2516) which it really needs to for two reasons: a) P772 is based upon P22 so the document needs to describe how the base P22 fields should be encoded. b) It would be beneficial if XSMTP could be able to be mapped to/from a X.400 P772 message at an appropriate gateway. 3) XSMTP Headings Extensions There are a number of confusions in the text. For example: * Priority Level Qualifier and Extended Grade of Delivery are in fact the same Element of Service in S4406. * The BNF for multi-valued fields is wrong and actually only allow 1 or 2 values (e.g. Distribution-Codes) * Some fields are defined as single-valued, when in fact they should be multi-valued (e.g. Message-Instructions) * Security-Classification must have a numeric value associated with the string form (like Primary-Precedence) * There really should be a Security Policy (OID) field defined to support the classification. * It is unclear which field Security-Classification refers to (my assumption is Content-Security-Label) * There should be a field for Security-Categories too (though I agree it would have a complex syntax). * An Address-List-Indicator is actually more complicated than just a string. 4) It is unclear which version/edition of S4406 XSMTP is based upon. 5) There is no discussion of MIME types that may be used for S4406-defined bodyparts. As it stands at the moment, I don't think that Format XSMTP is sufficiently well-defined to implement in MiliMail, and would benefit from a thorough review. Graeme |
|
