On Fri, Jan 22, 2010 at 1:20 PM, Stefano Bagnara <[email protected]> wrote:
> 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.
true
>> 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.
sounds about right
>>>> 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).
the idea would be to only support POP3+IMAP only with the new IMAP
stores and not support POP3+IMAP for the MailRepository stores
>> 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?
dunno
i'd be inclined just to use spring or guice to assemble it into the
mailets and leave context unchanged
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
