This document discusses what Software Developers need to know for compliance with GoodMessaging at the Basic, Bronze, and Silver levels of compliance. It will most likely only make sense after reading the GoodMessaging Introduction [1].

Openness

Open Standards

GoodMessaging compliance requires the use of only Open Protocols. All communication standards must be free for use by all, with no patents or any other proprietary mechanism. Additionally, these Open Protocols need to be well documented, and the software may use no incompatible proprietary extensions (ie. extra IMAP capabilities are fine, as long as software that doesn't use those capabilities still works with it).

Bronze: May not have any non-standards-based extensions. If you want to implement something non-standard, you must have it made into a standard first.

Validation

Message Standards Conformance

As well as the transfer of the message being according to open standards, the message itself needs to conform to the Internet message standards (MIME, or whatever is relevant). If it doesn't, it is the transmission endpoints' (MDA and MSA, in the case of e-mail) responsibility to rewrite it so that it does. This can be done with tools like Anomy Sanitizer or MIMEDefang.

Support

Any of the following fulfil this requirement:

• A community mailing list with 100 or more individuals subscribed
• Support from the developers (this doesn't mean hand-holding, merely an honest attempt to answer anyone who has read How To Ask Questions The Smart Way [14] and tried to do so)

Security

• All software must be IPv6 compliant
• All software must support per-transfer encryption (eg. STARTTLS) and verification (eg. DNSSEC [15] and SPF [16])
• All server software must authenticate all attached end-users. This includes:
  • MAA (ie. POP/IMAP) authentication
  • SMTP Authentication

Programming

The software needs to be secure.

User Agent Security

• Don't load things outside the message by default (ie. images that aren't attached to the current message, hrefs to things outside the message)
• Don't run untrusted content by default (eg. don't automatically execute JavaScript, don't automatically displaying files with executable content)

Flexibility

Virtual Hosting

Messaging server software (including POP/IMAP servers) must be able to deal with hosting multiple domains. Additionally, the differentiation between the domains must be domain based (ie. an IMAP server which has the two accounts "joe@example.com" and "joe@example.com.au" as two different accounts).

Mail User Agent: Support vCard/vCalendar

All GoodMessaging products should support the vCard/vCalendar [17] setup being worked on by the Internet Mail Consortium [18].

Additional Reading

• Glossary [19]
• Mail RFCs by Type [20] (from the Internet Mail Consortium [21])
• Standards on HTML in e-mail, organised message headers, and the like [22]
• Dan Bernstein's Internet Mail [23] page