Prev: Postfix sender reputation support in snapshot 20100117
Next: suppress NDRs from spoofed sender
From: "Daniel L. Miller" on 18 Jan 2010 01:44
I realize the developers and senior ops may be a bit irritated by some
of my recent queries. I plead ignorance - and a desire to improve.

I currently utilize ASSP as my primary filter. In the past, I have
heard that there is nothing ASSP does that cannot be done utilizing
alternative tools - in many cases built-in Postfix functionality.
Regardless of your opinion of ASSP, there is a particular feature which
I cannot replicate - hence my questions. That feature is auto-whitelisting.

The goal is simple - there are some people & businesses my company needs
to correspond with no matter how strict my filter, and no matter how
badly the remote site is configured. Waiting to receive a message
carrying critical business information is simply unacceptable - so I
need an alternative. ASSP provides me with one - by the simple act of a
user sending a message to a remote, that address and/or domain is
immediately whitelisted and immediately bypasses nearly all the spam
filters (virus scans still occur).

Daily scanning of logfiles does not accomplish this. Nor would even an
hourly scan - and constant logfile scanning strikes me as inelegant. If
there is any method currently existing within Postfix to accomplish this
goal please point me at it! If not, I'd like to discuss possible means
and methods for a future implementation.

--
Daniel

From: Sahil Tandon on 18 Jan 2010 10:45
On Sun, 17 Jan 2010, Daniel L. Miller wrote:

> The goal is simple - there are some people & businesses my company
> needs to correspond with no matter how strict my filter, and no
> matter how badly the remote site is configured. Waiting to receive
> a message carrying critical business information is simply
> unacceptable - so I need an alternative. ASSP provides me with one
> - by the simple act of a user sending a message to a remote, that
> address and/or domain is immediately whitelisted and immediately
> bypasses nearly all the spam filters (virus scans still occur).

I do not know of a stock Postfix feature that provides this
functionality. amavisd-new has 'pen pals' which does something similar
to what you desire. Question: does ASSP simply whitelist the envelope
sender if it matches the envelope recipient of a message sent by one of
your users? That is to say, are messages spoofed with whitelisted
envelope senders simply given a free pass through all your checks?

--
Sahil Tandon <sahil(a)tandon.net>

From: "Daniel L. Miller" on 18 Jan 2010 12:37
Henrik K wrote:
> On Sun, Jan 17, 2010 at 10:44:48PM -0800, Daniel L. Miller wrote:
>
>> Daily scanning of logfiles does not accomplish this. Nor would even an
>> hourly scan - and constant logfile scanning strikes me as inelegant. If
>> there is any method currently existing within Postfix to accomplish this
>> goal please point me at it! If not, I'd like to discuss possible means
>> and methods for a future implementation.
>>
>
> I've been meaning to make something like this for postfix, your post
> refreshed me. Amavisd-new penpals is ok (and you can make other custom
> queries to it's database), but it can't make MTA bypass all the ptr/helo/foo
> checks. My main problem is all bad SOHO servers etc that get blocked by
> those.
>
> It can be achieved with a simple policy daemon that records all outgoing
> recipients and/or relays and compares them for incoming messages, possibly
> adding a header that you can also reuse in SA for scoring.
>
I created one - the problem is execution. I took the greylist.pl and
tweaked it - and it now adds recipient addresses to a database very
simply. But I only want that to happen with valid senders/clients.
Placing this policy daemon, which always returns "dunno", in the
smtpd_recipient_restrictions very simply generates a list of recipients
- but without any validation. And duplicating validation within this
daemon strikes me as wasteful.

Ideally, I'd like this daemon called immediately upon successful
delivery, or at what Postfix determines as "successful delivery" based
on the remote server response. Without tailing the logfile I don't see
how else to accomplish it - but I don't LIKE that form of
implementation. Might be the only way to do it at this time - but
perhaps having such status messages available might be considered
sufficiently worthwhile to implement a new feature?

--
Daniel

From: Wietse Venema on 18 Jan 2010 12:45
Daniel L. Miller:
> Henrik K wrote:
> > On Sun, Jan 17, 2010 at 10:44:48PM -0800, Daniel L. Miller wrote:
> >
> >> Daily scanning of logfiles does not accomplish this. Nor would even an
> >> hourly scan - and constant logfile scanning strikes me as inelegant. If
> >> there is any method currently existing within Postfix to accomplish this
> >> goal please point me at it! If not, I'd like to discuss possible means
> >> and methods for a future implementation.
> >>
> >
> > I've been meaning to make something like this for postfix, your post
> > refreshed me. Amavisd-new penpals is ok (and you can make other custom
> > queries to it's database), but it can't make MTA bypass all the ptr/helo/foo
> > checks. My main problem is all bad SOHO servers etc that get blocked by
> > those.
> >
> > It can be achieved with a simple policy daemon that records all outgoing
> > recipients and/or relays and compares them for incoming messages, possibly
> > adding a header that you can also reuse in SA for scoring.
> >
> I created one - the problem is execution. I took the greylist.pl and
> tweaked it - and it now adds recipient addresses to a database very
> simply. But I only want that to happen with valid senders/clients.
> Placing this policy daemon, which always returns "dunno", in the
> smtpd_recipient_restrictions very simply generates a list of recipients
> - but without any validation. And duplicating validation within this
> daemon strikes me as wasteful.
>
> Ideally, I'd like this daemon called immediately upon successful
> delivery, or at what Postfix determines as "successful delivery" based
> on the remote server response. Without tailing the logfile I don't see
> how else to accomplish it - but I don't LIKE that form of
> implementation. Might be the only way to do it at this time - but
> perhaps having such status messages available might be considered
> sufficiently worthwhile to implement a new feature?

I'm not sure you are solving the right problem. What is the likelihood
that a local user specifies an invalid remote address, and how
problematic is it for your to have a few invalid remote addresses
on your whitelist? If you use a btree or hash database, they won't
slow down the database searches.

Valid addresses don't live forever, either. After some time you
will have to expire unused entries from your database anyway, so
you might just as well live with a minor degree of pollution from
the occasional invalid remote address.

Wietse

From: "Daniel L. Miller" on 18 Jan 2010 13:14
Wietse Venema wrote:
> Daniel L. Miller:
>
>> Henrik K wrote:
>>
>>> On Sun, Jan 17, 2010 at 10:44:48PM -0800, Daniel L. Miller wrote:
>>>
>>>
>>>> Daily scanning of logfiles does not accomplish this. Nor would even an
>>>> hourly scan - and constant logfile scanning strikes me as inelegant. If
>>>> there is any method currently existing within Postfix to accomplish this
>>>> goal please point me at it! If not, I'd like to discuss possible means
>>>> and methods for a future implementation.
>>>>
>>>>
>>> I've been meaning to make something like this for postfix, your post
>>> refreshed me. Amavisd-new penpals is ok (and you can make other custom
>>> queries to it's database), but it can't make MTA bypass all the ptr/helo/foo
>>> checks. My main problem is all bad SOHO servers etc that get blocked by
>>> those.
>>>
>>> It can be achieved with a simple policy daemon that records all outgoing
>>> recipients and/or relays and compares them for incoming messages, possibly
>>> adding a header that you can also reuse in SA for scoring.
>>>
>>>
>> I created one - the problem is execution. I took the greylist.pl and
>> tweaked it - and it now adds recipient addresses to a database very
>> simply. But I only want that to happen with valid senders/clients.
>> Placing this policy daemon, which always returns "dunno", in the
>> smtpd_recipient_restrictions very simply generates a list of recipients
>> - but without any validation. And duplicating validation within this
>> daemon strikes me as wasteful.
>>
>> Ideally, I'd like this daemon called immediately upon successful
>> delivery, or at what Postfix determines as "successful delivery" based
>> on the remote server response. Without tailing the logfile I don't see
>> how else to accomplish it - but I don't LIKE that form of
>> implementation. Might be the only way to do it at this time - but
>> perhaps having such status messages available might be considered
>> sufficiently worthwhile to implement a new feature?
>>
>
> I'm not sure you are solving the right problem. What is the likelihood
> that a local user specifies an invalid remote address, and how
> problematic is it for your to have a few invalid remote addresses
> on your whitelist? If you use a btree or hash database, they won't
> slow down the database searches.
>
> Valid addresses don't live forever, either. After some time you
> will have to expire unused entries from your database anyway, so
> you might just as well live with a minor degree of pollution from
> the occasional invalid remote address.
>
I cheated - I went right past sender validation and started discussing
recipient verification. Because Postfix already does (or can do)
recipient verification, I like the thought of keeping the whitelist
clean. You're of course correct that the whitelist would need
expiration at some point.

But my primary issue is sender validation. I don't see how, currently,
to implement this as a policy daemon without re-writing sender
validation into the policy daemon. I don't see any way, for example, to
call another policy daemon after permit_sasl_authenticated returns "OK".

--
Daniel

 |  Next  |  Last
Pages: 1 2 3 4 5 6
Prev: Postfix sender reputation support in snapshot 20100117
Next: suppress NDRs from spoofed sender