I agree with all of what you have said. I have no particular desire to
change JAMES behaviour here, as it is probably more effort than it is
worth. (I think that putting mail handling rules in the SMTP dialog
handler instead of the processor would be a bad trade off to make. If I am
not mistaken, that would be the only way to achieve it, right?)
The perception of this by non-technical clients is something to be aware
of, however. I have struck situations where clients have had the black
hole thing pointed out to them by those proposing alternate solutions. It
does tend to make them uneasy.
As for the blackhole behind the firewall scenario - you are absolutely
right. On thinking about it, I suspect this is actually preferable to
rejection. If the firewall does not do its job properly, rejecting the
mail afterward will not help and may even create problems.
ADK
--------------------------------------------
There is no magic.
"Danny Angus"
<danny@apache. To: "James Users List"
<[EMAIL PROTECTED]>
org> cc:
Subject: RE: My first contact with James
29/11/2002
10:44
Please respond
to "James
Users List"
I know, we've had this discussion before.
In actual fact most mail servers behind SMTP forwarding firewalls will be
blackholes for spam as James is.
Additionally it has been a goal to eventually achieve some kind of
rejection of obvious spam , but this would have to be coherent with the
style of James. In other words optional, modular, and either highly
configurable or dead simple.
I'm not in the least opposed to handling spam this way and I've seen (rare)
instances where spammers mistake a blackhole for a relay, but on the whole
spammers test MTAs for relaying before they waste their own bandwidth and
clock cycles pouring mail into a blackhole.
And don't forget that rejecting mail is a two way street, every recipient
address which you reject because of "unknown recipient" helps automated
address harvesters build up more accurate lists of real addresses to spam,
and spam targeted at real addresses is the real problem.
d.
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: 28 November 2002 23:00
> To: James Users List
> Subject: RE: My first contact with James
>
>
>
> We would prefer JAMES to refuse mail that did not match its accept
> criteria. I have installed mail servers for many companies. I cannot
> think of a single one that would be happy with the concept of paying for
> the bandwidth that would be used up in receiving mail that it was
> not going
> to process. (Regardless of actual likelihood of this happening, or real
> world numbers, most clients are not keen on the /idea/.)
>
> However I can see that that might be difficult to do with JAMES. We hide
> JAMES behind a firewall for precisely this reason. It is not
> really such a
> big deal in my current situation, because JAMES is never going to be used
> as our corporate mail server. JAMES only receives mail that needs to be
> processed by our java code.
>
> Obviously, this is not the way everyone uses (or should use) JAMES. It
is
> one way of dealing with the spam issue, however.
>
> ADK
>
> --------------------------------------------
>
> There is no magic.
>
>
>
>
> "Danny Angus"
>
> <danny@apache. To: "Nebril de la
> Fuente, Victor" <[EMAIL PROTECTED]>
> org> cc: "James User
> List" <[EMAIL PROTECTED]>
> Subject: RE: My
> first contact with James
> 29/11/2002
>
> 07:51
>
> Please respond
>
> to "James
>
> Users List"
>
>
>
>
>
>
>
>
>
> Victor,
>
> > But James acept the message and then do not process it. A mail
> > server shouldn�t accept the message if is a spam.
>
> Thats your opinion, there are good reasons why James accepts mail.
> These reasons have been discussed a lot, if you want to find out I
suggest
> you check the mail archives.
> James is not an open relay for spam.
>
> d.
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]
>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]
>
-----------------------------------------------------------------------------------------------
Have you seen our website?.... http://www.vodafone.co.nz
CAUTION: This correspondence is confidential and intended for the named
recipient(s) only.
If you are not the named recipient and receive this correspondence in
error, you must not copy,
distribute or take any action in reliance on it and you should delete it
from your system and
notify the sender immediately. Thank you.
Unless otherwise stated, any views or opinions expressed are solely those
of the author and do
not represent those of Vodafone New Zealand Limited.
Vodafone New Zealand Limited
21 Pitt Street, Private Bag 92161, Auckland, 1020, New Zealand
Telephone + 64 9 357 5100
Facsimile + 64 9 377 0962
--
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]
>
-----------------------------------------------------------------------------------------------
Have you seen our website?.... http://www.vodafone.co.nz
CAUTION: This correspondence is confidential and intended for the named recipient(s)
only.
If you are not the named recipient and receive this correspondence in error, you must
not copy,
distribute or take any action in reliance on it and you should delete it from your
system and
notify the sender immediately. Thank you.
Unless otherwise stated, any views or opinions expressed are solely those of the
author and do
not represent those of Vodafone New Zealand Limited.
Vodafone New Zealand Limited
21 Pitt Street, Private Bag 92161, Auckland, 1020, New Zealand
Telephone + 64 9 357 5100
Facsimile + 64 9 377 0962
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
