> -----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]>
