[jdev] RFC 3921 message to RFC 5322 message conversion
da-jdev at weeno.net
Tue Jan 5 05:55:57 CST 2010
Tue, 05 Jan 2010 11:02:42 +0100, Tomasz:
> 1. How do i store 'from' and 'to' fields of the XMPP message?
> RFC 5322 defines From: as mailbox-list and To: as address-list which
> in turn reduces to addr-spec which does not include schema and is
> assumed to be in SMTP domain.
If there is no way to contact the sender of the message via SMTP (or
to refer to the recipient), I think you should either leave the field
empty (which I'm not sure is legal), or forge an address. Some
solutions that come to mind are:
A. converting the sender JID to an SMTP address at a Jabber-to-SMTP
gateway of your choice. IMHO, it's obviously the best solution, if
B. using the mail address of the person responsible for the IMAP store.
C. using a clearly invalid address.
For solutions B. and C., you should maybe put the sender JID in the
realname part of the address, in order to compensate the loss of
> ":" is used to delimiter group names so
> we cannot use XMPP URI there.
Indeed, I don't think any URI is really easy to use in those fields.
> - Should I add X- header for preserving XMPP 'from' field? What exact?
What about the Jabber-ID header? If I understood it correctly, it seems
to be exactly its role: indicating a way to contact the sender of an
email via XMPP.
> - Should I fill From: and To: fields to maka maile readers usable?
I would say: if and only if you have any pertinent information to give
If you don't have any for the To: field, I think you should drop it.
After all, whenever one receives an email and they were mentionned as
Bcc:, their address doesn't appear, and it never hurt anyone.
The problem is the From: field is mandatory. Well actually it's not,
but in case it's not present, the Sender: field must be present, so the
problem stays the same. ;)
> 3. <thread/> converts directly to References:
Indeed. My first doubt was that References: and In-Reply-To: should
contain a _message_ identifier and not a _thread_ identifier, but RFC
822 explicitely mentions a "previous correspondence which this
message answers", a msg-id being a particular case.
In real-life implementations, though, I think most MUAs try to find a
msg-id that matches the contents of the header. So maybe you should
fill this field with the Message-ID you mention in your next
> 4. Should I generate Message-ID header? If so, how? Maybe it would be
> useful to base it on some of the message characteristics?
I think you should. The format is free as long as the resulting value
is unique. As you said, I guess any algorithm including some message
characteristics would be appropriate. These can be a mix of:
- the "id" if present, first and obviously.
- the "from" attribute
- the "to" attribute
- a timestamp
Another option can be a non-ambiguous hash (MD5, SHA-*) of the whole
In any case, I don't think you should include any random data of data
that is unique to the IMAP store: if the user happens to use various
SMTP stores (e.g. a private one and a public one), the Message-IDs
should be consistent between every store, so the calculation should be
as deterministic as possible.
More information about the JDev