You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-user@james.apache.org by Timo Nentwig <ti...@nitwit.de> on 2003/07/13 16:42:21 UTC
SpamAssassin for JAMES?
Hi!
SpamAssassin seems to be quite a good spam filter - but it's written in PERL. Are there any attempts to port it as a mailet?
Timo
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org
RE: Out going AUTH
Posted by Danny Angus <da...@apache.org>.
woops meant this for the developers list, sorry.
> -----Original Message-----
> From: Danny Angus [mailto:danny@apache.org]
> Sent: 14 July 2003 15:47
> To: James Users List
> Subject: Out going AUTH
>
>
> Regarding the outgoing use of SMTP AUTH for gateways, I think
> this should be
> pretty simple to add if anyone has the time, it should be a
> matter of adding
> the server and its credentials to the session and getting a
> transport using
> the URL, which will then use AUTH if credentials are available.
>
> d.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
> For additional commands, e-mail: server-user-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org
RE: Out going AUTH
Posted by "Noel J. Bergman" <no...@devtech.com>.
Danny wrote:
> No I was merely observing that AUTH seems designed to identify people
> who may be permitted, not machines.
Actually, I was re-reading http://james.apache.org/rfclist/smtp/rfc2554.txt.
It can be used to authenticate one SMTP server to another. Then the sending
server can use:
MAIL FROM: <fr...@shire.me> AUTH=frodo@shire.me
to indicate that it authenticated frodo (or trusts a server that had
similarly relayed for an authenticated sender). According to RFC 2554
section 5, if James cannot authenticate the sender, and wants to relay using
SMTP AUTH, then after authenticating itself, James should use:
MAIL FROM: <fr...@shire.me> AUTH=<>
to indicate that frodo@shire.me was not authenticated. It is permissible to
use AUTH=<>, and never authenticate senders.
> Also that it is possible to associate credentials with outward hosts in
> javamail therfore it should be straightforward to associate ONE set of
> credentials with a gateway in RemoteDelivery.
Perhaps not so straightforward. JavaMail's SMTP transport doesn't appear to
support the MAIL FROM AUTH= extension. A gateway server would have to be
configured to specifically trust the connecting James server, and credit the
sender as if authenticated. That could be a bad idea, because mail being
delivered from a non-trusted sender intended for a local user, from a
trusted sender wanting to relay, and from a non-trusted sender trying to
relay, would be indistinguishable.
Something to pass onto Bill Shannon, and a simple change (JavaMail already
supports a similar extension, MAIL FROM RET=), but I'm afraid that we may
have missed the window to get it into JavaMail.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org
RE: Out going AUTH
Posted by Danny Angus <da...@apache.org>.
> You want a authenticate a SERVER identity, as opposed to a SENDER
> identity?
No I was merely observing that AUTH seems designed to identify people who
may be permitted, not machines.
Also that it is possible to associate credentials with outward hosts in
javamail therfore it should be straightforward to associate ONE set of
credentials with a gateway in RemoteDelivery.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org
RE: Out going AUTH
Posted by "Noel J. Bergman" <no...@devtech.com>.
Danny,
> Regarding the outgoing use of SMTP AUTH for gateways,
> it should be a matter of adding the server and its
> credentials to the session
You want a authenticate a SERVER identity, as opposed to a SENDER identity?
My thought had been that Vincenzo is working on getting Soren's mail
attributes integrated into James (v2 and HEAD) now. Once we have those, I
had thought that we could preserve the sender's SMTP AUTH information.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org
Out going AUTH
Posted by Danny Angus <da...@apache.org>.
Regarding the outgoing use of SMTP AUTH for gateways, I think this should be
pretty simple to add if anyone has the time, it should be a matter of adding
the server and its credentials to the session and getting a transport using
the URL, which will then use AUTH if credentials are available.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org
RE: SpamAssassin for JAMES?
Posted by Steve Brewin <sb...@synsys.com>.
> -----Original Message-----
> From: Sheldon Hearn [mailto:sheldonh@starjuice.net]
> Sent: 14 July 2003 11:42
> To: James Users List
> Subject: Re: SpamAssassin for JAMES?
>
>
> On (2003/07/13 16:42), Timo Nentwig wrote:
>
> > SpamAssassin seems to be quite a good spam filter - but it's written
> > in PERL. Are there any attempts to port it as a mailet?
>
> Mad idea. :-)
>
> Better idea would be to write a mailet that implements the client side
> of the spamd protocol, to talk to the long-lived spamd process using
> TCP.
Yes, there seems to be a lot of cases cropping up where what is really
needed is a mailet that delegates work off to an external process. This
pattern is much more flexible than embedding everything in James.
Perhaps an AbstractDelegatingMailet could be written to inspire people to go
in that direction, though off-hand I can't think what extra functionality it
would provide that org.apache.mailet.GenericMailet doesn't!
-- Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org
Re: SpamAssassin for JAMES?
Posted by Sheldon Hearn <sh...@starjuice.net>.
On (2003/07/13 16:42), Timo Nentwig wrote:
> SpamAssassin seems to be quite a good spam filter - but it's written
> in PERL. Are there any attempts to port it as a mailet?
Mad idea. :-)
Better idea would be to write a mailet that implements the client side
of the spamd protocol, to talk to the long-lived spamd process using
TCP.
Ciao,
Sheldon.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org
RE: SpamAssassin for JAMES?
Posted by Steve Brewin <sb...@synsys.com>.
> Hi!
>
> SpamAssassin seems to be quite a good Spam filter - but it's
> written in PERL. Are there any attempts to port it as a mailet?
I don't believe a port would be the right way to go since you would then be
splitting the code base between Perl and Java implementations, introducing a
maintenance chore of keeping the two implementations in sync.
A mailet could invoke the Perl implementation, either via one of the
Java->Perl invocation APIs such as JPL (haven't tried it, just found it with
a google) or a simple exec.
What does SpamAssassin do that isn't already available in James? Perhaps
just that extra functionality, if any, could be added as one or more mailets
if its felt to be useful.
Incidentally, once the ScriptedMailet support I recently submitted is
integrated into the build you could also use that, but this relies on BSF
(Bean Scripting Framework) which currently only supports Perl on Win32
platforms.
-- Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org