[ http://issues.apache.org/jira/browse/JAMES-663?page=all ]
Noel J. Bergman reassigned JAMES-663:
-
Assignee: Noel J. Bergman
> sendmail.py crashes on line "from_addr = os.environ['USER'] + '@' +
> socket.getfqdn()"
>
[ http://issues.apache.org/jira/browse/JAMES-662?page=all ]
Noel J. Bergman reassigned JAMES-662:
-
Assignee: Noel J. Bergman
> sendmail.py doesn't handle multiple TO-recipients
> -
>
> K
Working now. One more change was necessary to another mail server.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
On 10/24/06, Danny Angus <[EMAIL PROTECTED]> wrote:
On 10/22/06, robert burrell donkin <[EMAIL PROTECTED]> wrote:
> hi
>
> (as some will know) i've been working on an OpenPGP/MIME (RFC3156)
> signing mailet. my reading of the specification leads me to believe
> that i should canonicalise the cont
cheers :-)
On 10/28/06, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
Working now. One more change was necessary to another mail server.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-ma
Hi,
I've started to explain and discuss my proposed refactorings to the
mailet API on [EMAIL PROTECTED]
The refactorings can be seen in the server/sanbox in svn.
*briefly* I'm moving certain entities which I believe are universal to
the server model of email into the API.
These are initially u
ImapServer sometimes throws Nullpointer
---
Key: JAMES-669
URL: http://issues.apache.org/jira/browse/JAMES-669
Project: James
Issue Type: Bug
Components: IMAPServer
Reporter: Norman M
Author: danny
Date: Sat Oct 28 03:59:20 2006
New Revision: 468677
URL: http://svn.apache.org/viewvc?view=rev&rev=468677
Log:
Added (empty) Status file
Added:
james/server/trunk/STATUS
Added: james/server/trunk/STATUS
URL: http://svn.apache.org/viewvc/james/server/trunk/STATUS?view=auto&rev=4
Hi Danny,
first its nice to see you code again ;-)
I don't like your changes to much. I think it make no sense to move the
Interfaces... I think we allready talked about that the MailRepository
will probaly replaced by a MessageRepository. The UserRepository
features will also replaced by the
robert burrell donkin wrote:
On 10/24/06, Danny Angus <[EMAIL PROTECTED]> wrote:
On 10/22/06, robert burrell donkin <[EMAIL PROTECTED]> wrote:
> hi
>
> (as some will know) i've been working on an OpenPGP/MIME (RFC3156)
> signing mailet. my reading of the specification leads me to believe
> that
On 10/28/06, Norman Maurer <[EMAIL PROTECTED]> wrote:
I don't like your changes to much. I think it make no sense to move the
Interfaces... I think we allready talked about that the MailRepository
will probaly replaced by a MessageRepository. The UserRepository
features will also replaced by the
[ http://issues.apache.org/jira/browse/JAMES-245?page=all ]
Norman Maurer closed JAMES-245.
---
Resolution: Fixed
The code works and danny allready open a issue for deprecating
> Deprecated in imap2
> ---
>
> Key: JAMES-245
>
[
http://issues.apache.org/jira/browse/JAMES-669?page=comments#action_12445378 ]
Norman Maurer commented on JAMES-669:
-
Ok the NPE is thrown cause it extends AbstractLogEnabled but no logger is init
for the class via ContainerUtil. I saw tha
Hi all!
I guess it is wished that the API for just accessing user inboxes should
stay as easy as possible.
That's why I'm proposing a separate Interface that only contains core
functionalities.
Just like addUser has been moved from James class to UsersRepository,
getUserInbox could be moved to
On 10/28/06, Joachim Draeger <[EMAIL PROTECTED]> wrote:
Okay there is one point that is a bit more difficult:
ToRepository Mailet, which accepts a url.
It is used for mail that is not delivered to a user like spam or mail
that can't be delivered.
I guess the ability to put this repositories wher
Am Samstag, den 28.10.2006, 18:07 +0100 schrieb Danny Angus:
> On 10/28/06, Joachim Draeger <[EMAIL PROTECTED]> wrote:
>
> > Okay there is one point that is a bit more difficult:
> > ToRepository Mailet, which accepts a url.
> > It is used for mail that is not delivered to a user like spam or mai
Am Freitag, den 27.10.2006, 20:45 +0200 schrieb Bernd Fondermann:
> > BTW: if everything runs well with Spring, which advantages brings us
> > staying with phoenix, apart from backward compatibility with custom
> > code?
>
> + everyone in the dev team knows Avalon/Phoenix
> + it is proven to run
Joachim Draeger wrote:
Hi all!
I guess it is wished that the API for just accessing user inboxes should
stay as easy as possible.
That's why I'm proposing a separate Interface that only contains core
functionalities.
Just like addUser has been moved from James class to UsersRepository,
getUse
Joachim raeger wrote:
Am Freitag, den 27.10.2006, 20:45 +0200 schrieb Bernd Fondermann:
BTW: if everything runs well with Spring, which advantages brings us
staying with phoenix, apart from backward compatibility with custom
code?
+ everyone in the dev team knows Avalon/Phoenix
+ it is proven
Joachim Draeger wrote:
Am Samstag, den 28.10.2006, 18:07 +0100 schrieb Danny Angus:
On 10/28/06, Joachim Draeger <[EMAIL PROTECTED]> wrote:
Maybe we could use a logical #system name space here like #system.spam
or #system.address-error.
For example this could be mapped like: #system.* -> file:/
You guys have to decide what you want and build a consensus around
that. My group
intends to continue developing our mail server (although I've since
left JBoss/RedHat).
Initially we hoped to support the mailet API but there seems to be a
group who wants to
create an abstract cross-mailserver
Andrew C. Oliver wrote:
> You guys have to decide what you want and build a consensus around
> that.
Always. But ...
> Initially we hoped to support the mailet API but there seems to be a
> group who wants to create an abstract cross-mailserver API and another
> group who sees it as just an API
22 matches
Mail list logo
