[jdev] RFC 3921 message to RFC 5322 message conversion

[Dave Cridland]

On Tue Jan  5 11:55:57 2010, David Ammouial wrote:
> 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
>    technically possible.
> 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
> information.
> 
> 
I don't think B & C are at all practical, I'm sorry to say.

I think A is entirely practical. At minimum, I think you could use  
MIME-style encoding on the node, enclose that in quotes, and then ACE  
encode the domain. That loses resources, but I don't think that's a  
worry, given that you can also include that data in the original  
stanza.

Of course, if you do want a full SMTP/XMPP gateway, then you do need  
resources as well, and you probably need to have the gateway domain  
as the email address's domain, and the full jid (encoded and quoted)  
as the local-part. FWIW, I don't think that this is as interesting a  
problem as rich archival access.

> > - 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.
> 
> 
That's a good point. The problem is that it's just a header - there's  
little searching capability, and it won't appear nicely in the  
ENVELOPE fetch item.

> 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.

I don't see why consistency between implementations helps here. It's  
not as if we need that for email now, after all - different  
submission agents add message identifiers in all manner of ways, and  
certainly not consistently.

All that matters is that a given message has an identifier, which is  
(mostly) unique. (Message ids aren't entirely unique, and this  
doesn't hurt anyone).

If the intent is to reply to a message held in one IMAP store through  
an unassociated Submission server acting as a gateway and have it all  
work perfectly, then I'd have to raise the If It Hurts defense. :-)

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade