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:[email protected] - xmpp:[email protected]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
JDev mailing list
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: [email protected]
_______________________________________________
