Re: [mailet-api][proposal] MailAddress
Danny Angus ha scritto: > On 8/16/07, Norman Maurer <[EMAIL PROTECTED]> wrote: >> Stefano Bagnara schrieb: > >> I fully agree with Stefano, > > !! > > What is your point? That the API should enforce RFC compliance and not > the server? > Why? The servlet API doesn't enforce compliance with http or html > standards, the application server implementation might though. > > If we leave this up to implementors then it is up to users to choose > ones which comply with appropriate standards. I don't think it is the > job of the mailet api to constrain things beyond what is necessary to > ensure that mailets work and are portable. > > James, or buni, or mailcatcher should validate addresses for compliance. > > d. My point is the question I made to Robert: what is a Mail Address? Is every string in the world a mail address? Or just a subset of strings? IMHO the RFC tell us what is a mail address, anything more relaxed is probably only a string and may have no sense to some server out there. I don't understand why the API should tell us that a MailAddress is a strings tuple and nothing more. Why don't we say that a MailAddress is simply a *single* string? I don't get the choice behind this step. Why don't we use a byte array then (like Robert said few weeks ago this is what we receive on the wire, a bytearray ensure that we can represent what we received)? I understand the need of flexibility in the API, but I'm not convinced that we should relax *that* way. IMHO it is not true that we can leave the checks to the container: sometimes Mailets do write new addresses. In this case we would have mailet author to write their own implementation or depend on some specific container (using the container implementaion) ? Btw I've not strong positions on this, this is just my idea: I won't veto a similar change. I still anyway think that the basic discussion belongs to mailet-api list: at least the change to introduce an interface instead of a class should be discussed/decided in the mailet-api list. Why using MailAddress instead of InternetAddress, then? Is this a move to remove javamail dependencies? Also this topic belongs first to the mailet api list, IMHO. Conclusion: if you think that the API should only publish an interface then I would like to know what you propose as javadocs for that interface. Javadocs will be the only place where we can "suggest" contracts to the implementors. E.g: should an implementation be allowed to create MailAddresses returning NULLs in one or both of the string properties? Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mailet-api][proposal] MailAddress
On 8/16/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > IMHO it is not true that we can leave the checks to the container: > sometimes Mailets do write new addresses. In this case we would have > mailet author to write their own implementation No. > or depend on some > specific container (using the container implementaion) ? Yes, that. Because it is the container which will ultimately need to use the address for transport. and James would use this exact same class, it won't go away, it will just become James specific. > Btw I've not strong positions on this, this is just my idea: I won't > veto a similar change. Good, but I'd still like us to agree if possible. > I still anyway think that the basic discussion belongs to mailet-api > list: at least the change to introduce an interface instead of a class > should be discussed/decided in the mailet-api list. I've posted on that subject this morning. I'm asking server-dev if we want MailAddress in James. the API list can decide if we want it in the API, if it isn;t in the API and server-dev don;t want it it could still go into a RI. > Why using > MailAddress instead of InternetAddress, then? Is this a move to remove > javamail dependencies? Also this topic belongs first to the mailet api > list, IMHO. That topic certainly does. > Conclusion: if you think that the API should only publish an interface > then I would like to know what you propose as javadocs for that > interface. The current MailAddress methods. > Javadocs will be the only place where we can "suggest" > contracts to the implementors. E.g: should an implementation be allowed > to create MailAddresses returning NULLs in one or both of the string > properties? Thats for the api list to determine. In my opinion implementations should comply with one of the address spec standards, but I don't think there is any need for the api to say *which* one. If that standard permits local-part with no domain as a valid address then domain returning null is valid. If it forbids domain without local-part then local-part should be not-null for that implementation. If this causes problems for addresses which comply with a different specification then the server authors can choose whether to change their implementation to validate against more/other specifications or to remain strictly compliant with the original specification. RFC compliance is a topic I've talked about often on this list and elsewhere, I cannot understate the importance of strict compliance if we want the standards to retain their value. The difference in this case is that I have come to the conclusion that there is no need for the mailet api to police this compliance in order for the api to achieve its objectives. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mailet-api][proposal] MailAddress
On 8/16/07, Danny Angus <[EMAIL PROTECTED]> wrote: > server authors can choose whether to change > their implementation to validate against more/other specifications or > to remain strictly compliant with the original specification. And users can choose to use a competing product. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mailet-api][proposal] MailAddress
Danny Angus ha scritto: > On 8/16/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > >> IMHO it is not true that we can leave the checks to the container: >> sometimes Mailets do write new addresses. In this case we would have >> mailet author to write their own implementation > > No. > >> or depend on some >> specific container (using the container implementaion) ? > > Yes, that. Because it is the container which will ultimately need to > use the address for transport. and James would use this exact same > class, it won't go away, it will just become James specific. Not sure I understand this sentence: does this means that you also propose to introduce a factory in the api to obtain/parseStringInto MailAddresses objects because the container is not supposed to works only with the interface? Or does it means I can do new JamesMailAddress in my mailet and then I bind my mailet to that specific container? >> Btw I've not strong positions on this, this is just my idea: I won't >> veto a similar change. > > Good, but I'd still like us to agree if possible. You know I'm not a fan of compromised software solutions: I most time prefer a majority choice even if the final choice is not what I voted :-) >> Conclusion: if you think that the API should only publish an interface >> then I would like to know what you propose as javadocs for that >> interface. > > The current MailAddress methods. I just looked at MailAddress javadocs and really do not belong to the interface you are proposing. I'd like to understand how/if this MailAddress interface proposal can be related to other additional informations we may have in SMTP related to an email address (I refer to ESTMP DSN extension: ORCPT and NOTIFY extensions to the MAIL RCPT command, or to the ID we can pass in the MAIL FROM). Does it transport also the "personal name" like the InternetAddress or is it limited to the localpart+domain string tuple? Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mailet-api][proposal] MailAddress
On 8/15/07, Danny Angus <[EMAIL PROTECTED]> wrote: > I think that I agree with roberts issue regarding MailAddress (MAILET-9) > I would like to propose that the API specify an interface and possibly > an InternetAddress wrapper if we produce an RI. but that in general > the container should be concerned with RFC compliance decisions not > the API and therfore the existing MailAddress should move back to > james-server. > > WDYT? I think I grot MAILET-9 finally. I like MailAddress as an interface. I see 3 possible constructors/implementations... a) RFCStrictMailAddress (strict) b) StringMailAddress (loose) c) JavaMailAddress (wraps InternetAddress) I think if we pushed a) and b) to server-dev, then we would logically tell JavaMail to add c). I don't see that happening and don't believe it makes a lot of sense for any involved. I think it would look even weirder if 2 implementations are in another project but then the mailet API contains one other impl to another project. I agree with Danny that it's up to the server to manage the compliance, but I think it would do that by choosing the appropriate impl that's available in the mailet API. If it really needed something beyond that, there could be an extension in James server, but the standard impls should be bundled with mailet. I have concern about c)... would you expect setters called on MailAddress to reflect the underlying InternetAddress? I would assume so with a term "wrapper", but I don't think that's feasible to implement. Maybe it is. -- Serge Knystautas Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[JSieve] SMTP MAIL Envelope
i've revised the MailAdapter API so that the responsibility for parsing the addresses is push to the adapter. however, Envelope extends Address. i wondered whether this the API needs altering so that getEnvelopes returns addresses but i'm struggling to understand the envelope test in http://www.rfc-editor.org/rfc/rfc3028.txt. anyone care to take a look and offer an opinion? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [JSieve] SMTP MAIL Envelope
Robert Burrell Donkin ha scritto:
> i've revised the MailAdapter API so that the responsibility for
> parsing the addresses is push to the adapter. however, Envelope
> extends Address.
>
> i wondered whether this the API needs altering so that getEnvelopes
> returns addresses but i'm struggling to understand the envelope test
> in http://www.rfc-editor.org/rfc/rfc3028.txt.
>
> anyone care to take a look and offer an opinion?
>
> - robert
Disclaimer: I never read the Sieve specification and I don't have any
specific knowledge.
Reading the rfc paragraph about the envelope test I think that Envelope
is something more than an address.
For an SMTP environment envelope is composed by a "from" (the address
used in the MAIL FROM command) and a "to" (the address used in the RCPT
TO command and that caused the delivery to this specific user).
Maybe a method getEnvelopeAttributes should return a map {
"from" => Address-instance,
"to" => Address-instance
}
It is not clear:
1) what "to" should check in case of alias expansion/local forwarding
(the original smtp recipient or the rewritten recipient?).
2) is anything else but "from" and "to" allowed?
3) if 2 is true are multiple values for an identical envelope-part allowed?
Stefano
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Imap Idle Command
Hi all, are there any plans to implement the Imap Idle command? i will need it to a project that i'm developing, so if there are no plans to develop it, i will work on it myself. but i might need some help. what would be the right approach to do it? i probably should add imap idle to the command library, and then add a processor to handle the request, but how should i keep the connection open? to send the notifications back to the client? Cheers, Paulo F.
Re: Imap Idle Command
On 8/16/07, Paulo Sergio <[EMAIL PROTECTED]> wrote: > Hi all, hi paulo > are there any plans to implement the Imap Idle command? no immediate ones ;-) > i will need it to a project that i'm developing, so if there are no plans to > develop it, > i will work on it myself. glad to have a volunteer :-) > but i might need some help. not a problem > what would be the right approach to do it? > i probably should add imap idle to the command library, and then add a > processor to handle the request, > but how should i keep the connection open? an IMAP client creates and holds open a connection to the server throughout. the problem is that the current handler uses only one thread. > to send the notifications back to the client? this means moving to a SEDA based design. the medium term aim would be to move to MINA and nio but in the short term, a three thread implementation (input, output, processor) is a stepping stone which would probably be satisfactory for IDLE. this should be relatively easy to implement. the refactoring needs to be continued so that the encoders are not fed by a direct call but via messaging. one area which is going to require some legwork is the mailbox. each mailbox session (currently misnamed as mailbox) needs to feed events to a mailbox which can be subscribed to. this will allow any session to listen to changes made in any other. the IDLE processor should poll the IMAP sessions for changes, create messages and then send them down the pipe. (might be easier for me to explain this in a JIRA) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mailet-api][proposal] MailAddress
On 8/16/07, Danny Angus <[EMAIL PROTECTED]> wrote: > On 8/16/07, Norman Maurer <[EMAIL PROTECTED]> wrote: > > Stefano Bagnara schrieb: > > > I fully agree with Stefano, > > !! > > What is your point? That the API should enforce RFC compliance and not > the server? > Why? The servlet API doesn't enforce compliance with http or html > standards, the application server implementation might though. there are good why it's rare for an API to actully insist on a particular parser implementation warts and all. including the parsing code in the API means that any fix will require a complete new version of the API to be issued. if it's important that the address is RFC compliant then this can and should be stated clearly in the API. the parsing should be left to the implementor. > If we leave this up to implementors then it is up to users to choose > ones which comply with appropriate standards. I don't think it is the > job of the mailet api to constrain things beyond what is necessary to > ensure that mailets work and are portable. > > James, or buni, or mailcatcher should validate addresses for compliance. i'm not sure that it's the validation as much as the parsing that is important. there are ways that an address header could fail to be RFC822 compliant but still contain a parsable local part and domain. i'd be happy to insist that the data exposed by the implementation is valid RFC822 but feel it's important that there is implementation freedom for the parsing phase. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Imap Idle Command
Hi Robert, On 8/16/07, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: > > On 8/16/07, Paulo Sergio <[EMAIL PROTECTED]> wrote: > > Hi all, > > hi paulo > > > are there any plans to implement the Imap Idle command? > > no immediate ones ;-) > > > i will need it to a project that i'm developing, so if there are no > plans to > > develop it, > > i will work on it myself. > > glad to have a volunteer :-) > > > but i might need some help. > > not a problem > > > what would be the right approach to do it? > > i probably should add imap idle to the command library, and then add a > > processor to handle the request, > > but how should i keep the connection open? > > an IMAP client creates and holds open a connection to the server > throughout. the problem is that the current handler uses only one > thread. > > > to send the notifications back to the client? > > this means moving to a SEDA based design. but do you think i have to switch to a SEDA architecture ? or SEDA would just be a better option? the medium term aim would be > to move to MINA and nio but in the short term, a three thread > implementation (input, output, processor) is a stepping stone which > would probably be satisfactory for IDLE. this should be relatively > easy to implement. yes i think Mina is a good choice, it seems to have a lot people working with it, and i've seen some good reviews about it. but is these just an idea or there is really a plan to implement it? Cheers, Paulo F. the refactoring needs to be continued so that the encoders are not fed > by a direct call but via messaging. > > one area which is going to require some legwork is the mailbox. each > mailbox session (currently misnamed as mailbox) needs to feed events > to a mailbox which can be subscribed to. this will allow any session > to listen to changes made in any other. the IDLE processor should poll > the IMAP sessions for changes, create messages and then send them down > the pipe. > > (might be easier for me to explain this in a JIRA) > > - robert > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: [mailet-api][proposal] MailAddress
Robert Burrell Donkin ha scritto: > On 8/16/07, Danny Angus <[EMAIL PROTECTED]> wrote: >> On 8/16/07, Norman Maurer <[EMAIL PROTECTED]> wrote: >>> Stefano Bagnara schrieb: >>> I fully agree with Stefano, >> !! >> >> What is your point? That the API should enforce RFC compliance and not >> the server? >> Why? The servlet API doesn't enforce compliance with http or html >> standards, the application server implementation might though. > > there are good why it's rare for an API to actully insist on a > particular parser implementation warts and all. including the parsing > code in the API means that any fix will require a complete new version > of the API to be issued. > > if it's important that the address is RFC compliant then this can and > should be stated clearly in the API. the parsing should be left to the > implementor. I'm not telling that the parsing have to be part of the API. I'm telling I want to understand what is a MailAddress (as you propose to make it an interface) and what is the contract for the MailAddress. If it is simply 2 nullable strings, then I am against this change, even if I already declared I will not veto it: IMHO it does not make sense and does not help anyone (users/implementors) having a similar interface. >> If we leave this up to implementors then it is up to users to choose >> ones which comply with appropriate standards. I don't think it is the >> job of the mailet api to constrain things beyond what is necessary to >> ensure that mailets work and are portable. >> >> James, or buni, or mailcatcher should validate addresses for compliance. > > i'm not sure that it's the validation as much as the parsing that is > important. there are ways that an address header could fail to be > RFC822 compliant but still contain a parsable local part and domain. > i'd be happy to insist that the data exposed by the implementation is > valid RFC822 but feel it's important that there is implementation > freedom for the parsing phase. > > - robert Let's talk about what the MailAddress *javadocs* will say to users and implementors (as we cannot enforce any contract if it is an interface), then we'll be able to discuss on how to implement it in JAMES Server, IMHO. My main concern is about the mailet api, and not how server will implement it (that's why I didn't understand the bounce back to server-dev). IMHO trying to decide and agree that MailAddress must be an interface without discussing the real interface and the real contract behind the interface has no meaning. The decision about using an interface, an abstract class or a concrete class *depends* by the contract we want to expose... not viceversa. But maybe you already explained this and I missed or misunderstood it (too few sleep hours for me lately). Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
