Erik Espinoza wrote:
A BSD admin that can take qmailtoaster and make it run on BSD can
implmenet a firewall policy using ipf.
Sure ;-D. But you're not taking into account admin laziness.
ES, port 587 is all about SMTP-AUTH, meaning that tcprules shouldn't
really matter as it's all done through auth. Port 25 doesn't require
auth, therefore it would need independent control.
What possible scenario would we need to control port 587 independently
of port 25 and why?
This seems like unnecessary complication, with no pay off at all.
You know, that is the reason I'd like to see that files separated.
Submission service and SMTP service in fact serve for totally different
purposes. One is used for MUA->MTA message submission, other is used for
MTA-to-MTA message transfer. I can hardly see why should I use same
tcprules for totally different services?
In ideal world I would enable things like SPF and simscan only on SMTP
service, and domainkeys or dkim signing only on SUBMISSION service. And I
would never-ever add IP ranges with RELAYCLIENT="" to the tcprules for
SUBMISSION service as it will look like nonsence there - I always want my
users to auth themselves to use SUBMISSION service.
That is why I use separate rulesets for SMTP and SUBMISSION.
I asked nearly the same thing a couple of weeks ago and was told we use one
file. Since I consider much of what we do as a "basic" package and in many
cases a work in progress, I created a second tcpserver submission file for
my toaster box. Submission port usage is similar, but very different. It
even has different services for each (part of the reason i decided to
separate them)... if I typo the file for the smtp service (port 25),
tcp.smtp, it would take down my smtp service, but not my submission
service... thus making it easier to tell where the problem is... we already
separate the logs.
Not to mention I have totally different rules in each for handling things
like rbl lookups and friendly ip's. I know about putting firewall/spam
filters in front too.... we have a barracuda as an mx filter for some of our
domains (debian, non-toaster server) and it's ridiculous to have it go
through the scans too. Our debian box essentially allows the mailfilter ip
through unmolested and uses ":deny" for the rest because the customers are
pointed to the submission port already.
I used to setup port 26 for customers (before submission and didn't use smtp
auth's port) to get around isp's blocking port 25 to send (for our hosted
customers off-net). I allow relaying for friendly ip's through submission,
and others can auth and send without passing through spamscanning and rbl
lookups. For anything on port 25... tough... you get the works (either mx
level filtering on another box or rbl's/spam/clamd on the local server).
George
---------------------------------------------------------------------
QmailToaster hosted by: VR Hosted <http://www.vr.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
