Bypass content_fitler based on SASL auth

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Bypass content_fitler based on SASL auth

Ian R. Justman

Hi, all.

I'd like to know whether it is possible to bypass content_filter based
on whether someone has authenticated via SASL.

The situation:

I would like to build a machine that can function both to scrub
spam/viruses for incoming mail (to my clients) and handle outgoing mail
using SMTP-AUTH (from my clients) if they use port 25 (yes, I do know
about port 587, but getting that configured client-side takes a bit of
additional handholding to get the port changed).  I was wondering
whether it is possible to bypass content filtering based on whether a
user has successfully authenticated to the machine.  Since I do not have
additional IP addresses available to me, I have little choice but to use
the one IP address the machine has.

To simplify explanation, I'll show you a little step-by-step list of
what I'd like to do (plus I already have one other condition I'd like to
check for, which is whether the IP address connecting belongs to one of
my clients and is static) but I have already figured this out given the
docs):

1.  Client connects.
2.  My server checks to see if the IP address is one of those belonging
to a client.
3.  It is?  If so, then use the FILTER operation in an
access(5)-formatted file, which, as we know, overrides content_filter.
4.  It isn't?  If not, then did the connection use SASL with an
established account?
5.  It is (assuming the authentication process had a positive outcome)?
  If so, then bypass the "content_filter" directive.
6.  It isn't (either is an outside client IP address AND either did not
use authentication or authentication failed)?  If not, filter it as if
it were any other incoming mail.

Any thoughts on this one?  I'm probably going to invite criticism on
this one because of possible ways of subverting this setup, but that's a
risk I'm willing to take.

Thanks!

--Ian.

--
Ian R. Justman
UNIX hacker.  Anime fan.  Any questions?
ianj (at) ian-justman.com
Reply | Threaded
Open this post in threaded view
|

Re: Bypass content_fitler based on SASL auth

Sahil Tandon
Ian R. Justman <[hidden email]> wrote:

> I'd like to know whether it is possible to bypass content_filter
> based on whether someone has authenticated via SASL.

If users authenticate via the submission (587) port, you can modify the
service in master.cf with something like:

    -o content_filter=

--
Sahil Tandon <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Bypass content_fitler based on SASL auth

Ian R. Justman
Sahil Tandon wrote:

> Ian R. Justman <[hidden email]> wrote:
>
>> I'd like to know whether it is possible to bypass content_filter
>> based on whether someone has authenticated via SASL.
>
> If users authenticate via the submission (587) port, you can modify the
> service in master.cf with something like:
>
>     -o content_filter=
>

I'm not sure you comprehended what I was asking.

I'll present it again:

----
I would like to build a machine that can function both to scrub
spam/viruses for incoming mail (to my clients) and handle outgoing mail
using SMTP-AUTH (from my clients) if they use port 25 (yes, I do know
about port 587, but getting that configured client-side takes a bit of
additional handholding to get the port changed).
----

I probably should have said that I already have my server set up the way
you suggested I do so on the port 587 instance of smtpd in master.cf.

However, this was not what I was asking about.

I am very specifically asking about port _25_.  I'd like to be able to
bypass content_filter= based on whether the user has successfully
authenticated against an account that user has on my machine.

Thanks.

--Ian.

--
Ian R. Justman
UNIX hacker.  Anime fan.  Any questions?
ianj (at) ian-justman.com
Reply | Threaded
Open this post in threaded view
|

Re: Bypass content_fitler based on SASL auth

Sahil Tandon
Ian R. Justman <[hidden email]> wrote:

> I'm not sure you comprehended what I was asking.
                     
Careless reading on my part -- sorry for that.
       
> I am very specifically asking about port _25_.  I'd like to be able
> to bypass content_filter= based on whether the user has successfully
> authenticated against an account that user has on my machine.

See the example here, in particular the section that begins with "If
for some reason SASL users connect to port 25":

http://www200.pair.com/mecham/spam/bypassing.html#10

The example is specific to amavisd-new as a content_filter but you can
amend for your needs.

--
Sahil Tandon <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Bypass content_fitler based on SASL auth

Ian R. Justman
Sahil Tandon wrote:

> See the example here, in particular the section that begins with "If
> for some reason SASL users connect to port 25":
>
> http://www200.pair.com/mecham/spam/bypassing.html#10
>
> The example is specific to amavisd-new as a content_filter but you can
> amend for your needs.

Aha, I hadn't thought of it that way.  Since I do happen to use
amavisd-new here, this fits this bill VERY nicely.  Thanks for the angle
and I'll try it out in a bit.

On another machine I operate, I had one client shoot a good 3000 (yes,
that's three THOUSAND) mails for a mailblast through port 25 which is
fully filtered.  Since this is an older dual-processor Pentium III,
needless to say, it is supremely unfit for the task.  To clear the queue
of the backlog, I had to hand-set this thing to completely bypass the
filtering entirely because it caused such a great load on the system.

--Ian.

--
Ian R. Justman
UNIX hacker.  Anime fan.  Any questions?
ianj (at) ian-justman.com
Reply | Threaded
Open this post in threaded view
|

Re: Bypass content_fitler based on SASL auth

Ian R. Justman
Ian R. Justman wrote:

> Sahil Tandon wrote:
>
>> See the example here, in particular the section that begins with "If
>> for some reason SASL users connect to port 25":
>>
>> http://www200.pair.com/mecham/spam/bypassing.html#10
>>
>> The example is specific to amavisd-new as a content_filter but you can
>> amend for your needs.
>
> Aha, I hadn't thought of it that way.  Since I do happen to use
> amavisd-new here, this fits this bill VERY nicely.  Thanks for the angle
> and I'll try it out in a bit.

The "catch-all" rule described in that article did the trick.  As it
turns out, I was thinking of using this very filter action (FILTER) for
if any of my users' IPs matched, i.e. a rule that would NOT trigger
filtering.  I'll sheepishly admit that I hadn't thought of using it as a
"condition" to ACTUALLY trigger filtering.  :)  Of course, I had to turn
off any normal "content filtering" directives
(content_filter/smtpd_proxy_filter for post- and pre-queue respectively).

Though a suggestion if it has not been made already:  Possibly make it
configurable whether some permit_* rules (particularly permit_mynetworks
and permit_sasl_authenticated on port 25; definitely not "permit") will
allow direct queueing of a message, i.e. bypassing
smtpd_proxy_filter/content_filter.  That way, you can make a server
either be both a client and MX server (a server with an MX record
pointed at it) or be one or the other and make switching between
behaviors cleanly configurable.

Thanks.

--Ian.

--
Ian R. Justman
UNIX hacker.  Anime fan.  Any questions?
ianj (at) ian-justman.com
Reply | Threaded
Open this post in threaded view
|

Re: Bypass content_fitler based on SASL auth

mouss-2
Ian R. Justman wrote:

> Ian R. Justman wrote:
>> Sahil Tandon wrote:
>>
>>> See the example here, in particular the section that begins with "If
>>> for some reason SASL users connect to port 25":
>>>
>>> http://www200.pair.com/mecham/spam/bypassing.html#10
>>>
>>> The example is specific to amavisd-new as a content_filter but you
>>> can amend for your needs.
>>
>> Aha, I hadn't thought of it that way.  Since I do happen to use
>> amavisd-new here, this fits this bill VERY nicely.  Thanks for the
>> angle and I'll try it out in a bit.
>
> The "catch-all" rule described in that article did the trick.  As it
> turns out, I was thinking of using this very filter action (FILTER) for
> if any of my users' IPs matched, i.e. a rule that would NOT trigger
> filtering.  I'll sheepishly admit that I hadn't thought of using it as a
> "condition" to ACTUALLY trigger filtering.  :)  Of course, I had to turn
> off any normal "content filtering" directives
> (content_filter/smtpd_proxy_filter for post- and pre-queue respectively).
>

you can alos leave the content_filter at its "default" and use something
like

smtpd_sender_restrictions =
        check_client_access pcre:/etc/postfix/filter_auth
        permit_sasl_authenticated
        check_client_access pcre:/etc/postfix/filter_default

== filter_auth
#virus scan only
/./ FILTER scan:[127.0.0.1]:10586
# no scan. pass to next smtpd
#/./ FILTER scan:[127.0.0.1]:10025
# no scan, no next smtpd
#/./ FILTER dummy:

== filter_default
/./ FILTER scan:[127.0.0.1]:10024


note that if you disable address rewrite before the filter, you should
pass mail (even if not filtered) to the "after the filter" smtpd so that
rewrite happens. otherwise, your virtual aliases won't be expanded, ...
etc.

one should generally scan all mail for viruses. you can use clamstmp for
this. or you can use amavisd-new with policy banks.


> Though a suggestion if it has not been made already:  Possibly make it
> configurable whether some permit_* rules (particularly permit_mynetworks
> and permit_sasl_authenticated on port 25; definitely not "permit") will
> allow direct queueing of a message, i.e. bypassing
> smtpd_proxy_filter/content_filter.  That way, you can make a server
> either be both a client and MX server (a server with an MX record
> pointed at it) or be one or the other and make switching between
> behaviors cleanly configurable.
>

The "future" is for the separation of flows (25 vs 587). so when 587
becomes more widespread, this "feature" would be obsolete.

note that in the case of permit_mynetworks, you can redirect the flow to
port 587 with a NAT implementation.