2010/1/22 Robert Burrell Donkin <[email protected]>:
> transforming via standard JavaMail (rather than Stefano's amazing
> workaround) alters the email so that SMTP->IMAP delivery is no longer
> specification compliant. i suspect the same goes for POP3.
I'd like to add that in the last Javamail versions (1.4.2, 1.4.3)
things improved a lot, but anyway, I see many issue expecially wrt
Activation stuff that makes the whole thing too much "breakable" by
simply adding some library including a mailcap or similar stuff. As
mime parsing is so important to our architecture I think it is a good
choince anyway to use mime4j, even if this means more work initially.
> mime4j allows read only streaming partial pull parsing. most mailets
> just look at headers so this would be much more efficient and stop
> james dying when presented with a huge email. given mina, this would
> allow mail processing to begin before the mail is accepted and would
> allow unification between the micro mailets used by SMTP and mailets
> in the pipeline.
This is something I would be very interested. What is processed "in
protocol" and what is processed asynchronously in the spool should be
mainly a configuration choice.
>>> 4. there are subtle semantic differences between the meanings of flags
>>> in POP3, SMTP and IMAP
>>
>> SMTP Flags ? You lost me here..
>
> IMAP sets flags based on SMTP. JavaMail sets flags based on SMTP but
> not compatibly. IMAP-vs-POP3 eg POP3 delete has different semantics
> from IMAP's delete so separate flags are needed. (i suspect that most
> users wouldn't expect mail to disappear from IMAP just because a mail
> client has been configured with autodeletion.)
Great! I never thought at this. So you say that a single user
"mailstore" accessed with both IMAP and POP3 should not delete email
when accessed via pop3 with the delete on ? I don't know how other
products work with this regard: have you done any "survey" ? The only
one I know is Gmail and when you delete in POP3 it doesn't indeed
deletes your email for real. This is not only a change in the
"interface" of the repository but also a change in the functional
behaviour of the repository (or of our pop3 implementation).
(I'm not against, this, just trying to collect requirements, ideas).
> maybe:
>
> deliver(String URL, Mail mail)
>
> would be a reasonable first step. (i agree that we need to revise Mail
> but i think that can wait.)
I'm a fan of first steps :-) Usually the first step is always the more
difficult. Once we learn to make the first it will be easy to move
forward and back: one day we'll dance, too.
> deliver("james://usern...@localhost/", mail)
> [...]
> deliver("jcr://username:[email protected]/general", mail)
> [...]
> deliver("http://username:[email protected]/robert.donkin";, mail)
> [...]
> deliver("maildir:///rdonkin", mail)
So this "deliver" method is something you would add also to the
MailetContext, or something different?
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
