Hmmm speaking with my client hat on, it would be slick if I could forward spam I
receive back to my James server (i.e. to
spam@myJamesServersDomain) and have it spoof the original sender with an invalid
recipient error. If spammers are culling their
lists based on reject errors, maybe they would cull me and I wouldn't get any further
crud from them, or the spammers they sell
their lists to! I wonder if a mailet could handle this..... (and maybe even also
forward the spam on to [EMAIL PROTECTED]) ;-)
Or does the reject have to be almost immediate for this scheme to work?
Marc...
----- Original Message -----
From: "Danny Angus" <[EMAIL PROTECTED]>
To: "James Users List" <[EMAIL PROTECTED]>
Sent: Friday, November 29, 2002 2:11 AM
Subject: RE: My first contact with James
>
>
> > -----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]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
