Thank you for those who took the time to fill out James user survey at
http://infopoll.net/live/surveys/s19892.htm
If you have not completely the survey, take take a few minutes to complete
it.
As promised, the updated survey report can be viewed directly from the URL
below:
http://infopoll.net/live/surveys.dll/r?sid=19892&r=29845
Thanks,
Alice
----Original Message Follows----
From: "Danny Angus" <[EMAIL PROTECTED]>
Reply-To: "James Users List" <[EMAIL PROTECTED]>
To: "James Users List" <[EMAIL PROTECTED]>
Subject: RE: My first contact with James
Date: Fri, 29 Nov 2002 10:11:57 -0000
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: 29 November 2002 01:24
> To: James Users List
> Subject: RE: My first contact with James
Aaron.
> 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?)
Right, this is the dilemma, it would obfuscate James configuration to have
an additional set of configurable rules here.
> 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.
I do understand this, but IMO the arguments for both approaches are equally
compelling, tell them that rejecting mail at the border will allow their
genuine addresses to be harvested, and that SMTP auth will reject much of
the mail intended for illicit relaying at the border without revealing local
usernames.
> As for the blackhole behind the firewall scenario - you are absolutely
> right. On thinking about it, I suspect this is actually preferable to
> rejection.
IMO blackholes are preferable to rejection on the basis that they provide no
information whatsoever to the sender, this is one guiding principle of
firewalls, try telnetting to a port protected by a firewall and your
connection just times out, you have no idea whether you were denied access,
if there was a problem connecting, or even if the machine really exists on
the network.
By the same token I believe that spam blackholes leave potential spammers
unable to determine if a real mail service is running, if it is broken, or
if their mail has been rejected, and it certainly doesn't help them to
determine who the real local users may be.
In my experience spammers will probe SMTP with mail sent to themselves via
an MTA, if that mail is not recieved (and blackholes, by definition, don't
deliver it) they will move on and look for other MTA's to probe.
I've seen as many as a dozen such probe attempts in a single day, but no
more than this and usually only one or two, this doesn't eat up bandwidth by
even a fraction of that used by unsolicited mail sent to real users, hence
my rather greater concern for obscuring the genuine mail addresses on a
domain.
Only once in almost two years have I encountered a spammer who dumped mail
into James without checking it out first, and this would not have happened
if the server were demanding SMTP auth.
d.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
_________________________________________________________________
The new MSN 8: advanced junk mail protection and 2 months FREE*
http://join.msn.com/?page=features/junkmail
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
