wissel.net

Usability - Productivity - Business - The web - Singapore & Twins

Lotus Domino and RFC


In a recent request by a government customer we were asked about the compliance of Domino with various RFC. I've listed them here for reference:
RFC Description Domino Remarks
RFC 1123 Requirements for Internet Hosts Application and Support (STD 3) Yes
RFC 1870 SMTP Service Extension for Message Size Declaration (obsoletes: RFC 1653) Yes
RFC 2476 Message Submission Obsolete see RFC 4409 below.
RFC 2505 AntiSpam Recommendations for SMTP MTAs (BCP 30) Yes
RFC 5321 The Simple Mail Transfer Protocol (obsoletes RFC 821 aka STD 10, RFC 974, and RFC 1869, RFC 2821) Yes
RFC 5322 Internet Message Format (obsoletes RFC 822 aka STD 11, and RFC 822) Yes
RFC 2920 SMTP Service Extension for Command Pipelining (STD 60) Yes
RFC 3030 SMTP Service Extensions for Transmission of Large and Binary MIME Messages No
RFC 3207 SMTP Service Extension for Secure SMTP over Transport Layer Security (obsoletes RFC 2487) Yes
RFC 3461 SMTP Service Extension for Delivery Status Notifications (obsoletes RFC 1891) Yes
RFC 3462 The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages (obsoletes RFC 1892) Yes
RFC 3463 Enhanced Status Codes for SMTP (obsoletes RFC 1893 ) Yes
RFC 3464 An Extensible Message Format for Delivery Status Notifications (obsoletes RFC 1894) Yes
RFC 3834 Recommendations for Automatic Responses to Electronic Mail Yes
RFC 4409 Message Submission for Mail (obsoletes RFC 2476) Partial Domino can be configured to act as an MSA, but is not strictly compliant (e.g. does not qualify unqualified domains in addresses)
RFC 4952 Overview and Framework for Internationalized Email This is not a standard - only an informational document
RFC 4954 SMTP Service Extension for Authentication (obsoletes RFC 2554) Yes
RFC 5068 Email Submission Operations: Access and Accountability Requirements (BCP 134) Yes This is not a standard - it is a document describing a set of operational best practices. Domino can be configured to support these practices

Posted by on 13 April 2009 | Comments (4) | categories: Show-N-Tell Thursday

Comments

  1. posted by Dave Harris on Tuesday 14 April 2009 AD:
    Stephan,

    How do others compare (Exchange, SendMail, qmail, etc)?
  2. posted by Stephan H. Wissel on Wednesday 15 April 2009 AD:
    @Dave: You have to ask the others. We don't track their compliance to RFCs.
    Emoticon biggrin.gif stw
  3. posted by Claus Allweil on Thursday 16 April 2009 AD:
    Hi Stephan,
    thanks for publishing. Perfect listing, I will reuse that.

    Claus
  4. posted by Christoph on Thursday 14 April 2016 AD:
    Lotus Notes is not RFC 5322 compliant!!
    In the RFC 5322 Standard the field From has a different purpose than in Lotus Notes, because it is always identifying the owner of the mail.box. Instead of using the field Principal to identify the owner of the mail.box in which an email was written, the field Sender is used to identify the effective user who produced the email.
    The field Principal is not (or better said no longer) accepted in the email header by many email providers and bounced back referring to being not RFC 5322 compliant. In messages produced by LotusScript directly in a document saved in the mail.box, you should use the field From instead of the field Principal and add the field Sender for the email address of the effective sender (sent by), who in a regular Lotus Email would be in the field From. If you prefer to have all replies to the effective sender instead of the person identified in the field From (original LN field Principal), you need to add the field ReplyTo with the same address as in der field Sender.
    Emoticon cry.gif