Re: [exim] how do I block mail to local domains except SMTP …

トップ ページ
このメッセージを削除
このメッセージに返信
著者: Mike Barnard
日付:  
To: Exim List
CC: exim-users
題目: Re: [exim] how do I block mail to local domains except SMTP auth or trusted source?
On Tue, Oct 7, 2008 at 6:46 AM, Exim List <eximlist@???> wrote:

> We have a machine with several domains. The MX record for these domains
> is pointed to a spam filter appliance.
>
> Alas, spammers don't play fair. They choose to connect directly to the
> IP address(es) of the domains on the box and still send their spam that
> way.
>


you lost me there.... if the the MX records are the spam filter
appliances... how did they get the IP addresses of the actual smtp
servers...


> While a firewall solution might seem the logical choice, it isn't here.
> The reason is that the users in each domain need to be able to see
> mail.abc.com or mail.xyz.com as their outgoing SMTP server which they
> relay through via SMTP auth.
>


and why would a firewall stop that from happening? unless i dont quite get
what you are saying, a firewall should work, depending of course on how you
set it up


> So, I need to know how to disable the ability to receive mail for local
> domains EXCEPT from a trusted source (the spam appliance box).



I would assume that the smtp servers receive/send email from the spam
filtering machines! If this is the case, then allow only the spam filtering
devices to send emails to your smtp servers

Further,
> I need to allow SMTP AUTH clients to relay mail through their respective
> domains.
>


i dont quite get 'relay mails through their respective domains'


>
> A firewall simply shuts off all SMTP traffic including SMTP auth unless
> I know all the "trusted sources" which is basically moot given roaming
> customers.
>


Then you are not configuring your firewall well...open the respective ports
required for mail. But this wont solve your problem.


> How can this be done?
>
> Also, it would be preferable to be able to do this on a domain by domain
> basis rather than server wide. If it can't be done that way, server
> wide is still better than what we have now.
>


You may need to look at your design again. It sounds more like a design flaw
than a configuration problem. When you get the design figured out and one
that works well for what you want to do, the configuration falls into place
pretty fast.



Regards,


--
Mike

Of course, you might discount this possibility, but remember that one in
a million chances happen 99% of the time.
------------------------------------------------------------