Hi,
On Mon, 20 Sep 2004, Sherwood Botsford wrote:
> > > In my logic, there is no valid reason that a remote
> > > sender would connect directly to our SMTP server from
> > > their dynamic/DSL/cable IP to send our customer's an
> > > email ... I think ? Valid 'remote to local' emails
> > > being
The school I work at is some 20 km from the nearest phone
exchange. DSL, ADSL, Cable are all non-starters here. We
connect through DirecPC oneway. So our outbound connection
is thorugh Telus, our local phone company. They refuse to
give out a static IP.
Ok, so run your smtp through their s
At 09:25 AM 9.20.2004 -0600, Sherwood Botsford wrote:
>
>> > In my logic, there is no valid reason that a remote
>> > sender would connect directly to our SMTP server from
>> > their dynamic/DSL/cable IP to send our customer's an
>> > email ... I think ? Valid 'remote to local' emails
>> > being s
On Mon, 20 Sep 2004, Sherwood Botsford wrote:
In this case, you should get a "smart host" on some other mail server, and
authenticate against that. You are still an endpoint, and should not be
directly talking to mail servers. Only mail servers should talk to mail
servers.
-Dan
In my logic,
> > In my logic, there is no valid reason that a remote
> > sender would connect directly to our SMTP server from
> > their dynamic/DSL/cable IP to send our customer's an
> > email ... I think ? Valid 'remote to local' emails
> > being sent from these DSL/cable/dialup IP would
> > normally be rel
Loren Wilton wrote:
>
> > In my logic, there is no valid reason that a remote sender would connect
> > directly to our SMTP server from their dynamic/DSL/cable IP to send our
> > customer's an email ... I think ? Valid 'remote to local' emails being
> > sent from these DSL/cable/dialup IP would n
> In my logic, there is no valid reason that a remote sender would connect
> directly to our SMTP server from their dynamic/DSL/cable IP to send our
> customer's an email ... I think ? Valid 'remote to local' emails being
> sent from these DSL/cable/dialup IP would normally be relayed via their
>
I found this type of rule to be very helpful in catching 'zombie spam
relay' emails from specific 'problem' networks.
The problem I faced with an all inclusive ban on these networks was that
our customer's connect to our SMTP servers from all around the world.
Banning Dynamic, DSL, Cable, or Dialu