As another user, I have been following this thread with some interest and have a
couple observations.....
1. As for the proposal from Randahl to notify the client, from my experience I will
have to argue, DON'T!!! I tried going the route
of notifying clients/spammers that I was dropping their spam into a bitbucket. What
often happened was that the From: address of the
spammer was bogus, and my server and the server that the client/spammer claimed to be
from would get into a pitched battle of
notifying each other that they were unauthorized or didn't exist... My ISP eventually
complained to me saying I was inadvertently
mounting a denial of service attack, and I had to reconfigure James to not attempt to
notify the sender that I was dropping the
spam....
2. I just tested my James against the tests at www.ordb.org . While I haven't got the
official response back from them yet, I did
receive a lot of notifications (via my postmaster address) that a lot of attempts were
made to relay mail through my server, from
the tests, and they were routed into the bit bucket... ;-) So, circumstantial evidence
seems to indicate that James is not an open
relay, as stated... If I hear otherwise from www.ordb.org I will let the group know...
Marc....
----- Original Message -----
From: "Randahl Fink Isaksen" <[EMAIL PROTECTED]>
To: "'James Users List'" <[EMAIL PROTECTED]>
Sent: Wednesday, May 22, 2002 12:10 PM
Subject: RE: Relay prevention
> Hi Danny and Noel
>
>
> Regarding the Spamlart test: I understand that JAMES may not transmit a
> mail even though it might seem so to the client. Without having any
> thorough insight into the design behind JAMES, I wonder if it would not
> be better for JAMES to respond immediately to the client with an
> "authorization required" or a similar clear message that indicates that
> spamming is not allowed. It is really a question of do we want to inform
> the spammers that their spamming failed? One could argue that it should
> be made hard for a spammer to figure out whether his spamming attempt
> succeeded, however, I think it is a waste of valuable clock cycles to
> have them keep on trying. Also, if JAMES was more clear in its client
> responses I would feel more certain that none of the on-line lists of
> open relays would list a JAMES mail server by mistake.
>
> Again, I am aware that there might be some design reasons to why JAMES
> responds the way it does - still, would it not be an advantage if it
> worked differently?
>
>
> Yours
> Randahl
>
>
> -----Original Message-----
> From: Noel J. Bergman [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 22, 2002 19:19
> To: James Users List
> Subject: RE: Relay prevention
>
> > Moreover the open relay database at www.ordb.org has now blacklisted
> my
> > JAMES installation
>
> I'll check my test system against ordb.org later.
>
> > testing it with spamlart made it flunk bigtime.
> >
> http://www.paladincorp.com.au/cgi-bin/spamlart.cgi?DESTINATION=test.rock
> it.d
> k
>
> It appears that spamlart bases its test upon the response during mail
> submission. As noted in the James FAQ, James (and it is not alone in
> this
> regard) performs mail filtering after the message is received.
> Spamlarts
> tests could form the basis for a Spam filter similar to that present in
> NESSpamCheck, but those rules would be processed during the delivery
> process, not the SMTPhandler.
>
> --- Noel
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
