Prev: SOLVED Re: gssapi sasl authentication
Next: The method behind the madness
From: Wietse Venema on 17 Jan 2010 17:38
postfix-2.7-20100117 changes the meaning of content filters of the
form "transport:" (note: no next-hop destination) so that this
form can be used to implement sender reputation schemes. Typically,
mail is split into classes, and all mail in class X is sent out
from an SMTP client IP address that is reserved for class X.

According to discussions on the Postfix list there is a legitimate
need for such functionality. Until now this requires one Postfix
instance per source IP address.

The change introduces one minor incompatibility. As always, there
is a compatibility option to restore the old behavior. This option
is not needed with SMTP-based content filters, because these always
have an explicit next-hop destination.

With pipe-based content filters that specify no next-hop destination,
the compatibility option restores the order of deliveries when a
filter is congested (it restores from per-destination round-robin
selection back to approximate FIFO selection).

More details in the release notes quotes below.

Wietse

Major changes with snapshot 20100117
====================================

The FILTER action in access maps or header/body_checks now supports
sender reputation schemes that dynamically choose the SMTP source
IP address.

This is implemented by specifying FILTER actions with empty next-hop
destinations in access maps or header/body_checks, and by configuring
in master.cf one Postfix SMTP client for each SMTP source IP address,
where each client has its own "-o myhostname" and "-o smtp_bind_address"
settings.

Incompatibility with snapshot 20100117
======================================

The meaning of an empty content filter next-hop destination has
changed. Postfix now uses the recipient domain, instead of using
$myhostname as in Postfix 2.6 and earlier. To get the old behavior
use "default_filter_nexthop = $myhostname", or specify a non-empty
next-hop content filter destination.

From: Victor Duchovni on 17 Jan 2010 18:43
On Sun, Jan 17, 2010 at 05:38:12PM -0500, Wietse Venema wrote:

> According to discussions on the Postfix list there is a legitimate
> need for such functionality. Until now this requires one Postfix
> instance per source IP address.

I am not entirely convinced the need is "legitimate", as this probably is
most useful for "snow-shoe" spam operations.

This said, it is not clear that having snow-shoe spammers using Postfix
is any worse then snow-shoe spammers using Sendmail, Qmail, Exim or
various commercial engines...

So long as the feature is reasonably useful to some non-spammers, we can
fight spam by means more effective than trying to deny them software...

--
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:majordomo(a)postfix.org?body=unsubscribe%20postfix-users>

If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.

From: Stan Hoeppner on 17 Jan 2010 18:50
Victor Duchovni put forth on 1/17/2010 5:43 PM:
> On Sun, Jan 17, 2010 at 05:38:12PM -0500, Wietse Venema wrote:
>
>> According to discussions on the Postfix list there is a legitimate
>> need for such functionality. Until now this requires one Postfix
>> instance per source IP address.
>
> I am not entirely convinced the need is "legitimate", as this probably is
> most useful for "snow-shoe" spam operations.
>
> This said, it is not clear that having snow-shoe spammers using Postfix
> is any worse then snow-shoe spammers using Sendmail, Qmail, Exim or
> various commercial engines...
>
> So long as the feature is reasonably useful to some non-spammers, we can
> fight spam by means more effective than trying to deny them software...

I tend to agree. There are a lot of snowshoe OPs out there, and they're already
using some smtp mailer engine successfully. I don't think this new feature is
going to create a mad rush of spammers adopting Postfix just for this.

--
Stan

From: Stefan Foerster on 18 Jan 2010 00:36
* Wietse Venema <wietse(a)porcupine.org>:
> This is implemented by specifying FILTER actions with empty next-hop
> destinations in access maps or header/body_checks, and by configuring
> in master.cf one Postfix SMTP client for each SMTP source IP address,
> where each client has its own "-o myhostname" and "-o smtp_bind_address"
> settings.

To be honest, I don't see what exactly has changed here. Manual pages
from a stock Postfix 2.6.5:

,----[ man 5 access ]
| FILTER transport:destination
| After the message is queued, send the entire message through the
| specified external content filter. The transport:destination
| syntax is described in the transport(5) manual page.
`----

,----[ man 5 transport ]
| A non-null transport field with a null nexthop field resets the nexthop
| information to the recipient domain.
`----

If my question is answered in other parts of the documentation, I
apologize in advance.


Stefan

From: Wietse Venema on 18 Jan 2010 09:32
Stefan Foerster:
> * Wietse Venema <wietse(a)porcupine.org>:
> > This is implemented by specifying FILTER actions with empty next-hop
> > destinations in access maps or header/body_checks, and by configuring
> > in master.cf one Postfix SMTP client for each SMTP source IP address,
> > where each client has its own "-o myhostname" and "-o smtp_bind_address"
> > settings.
>
> To be honest, I don't see what exactly has changed here. Manual pages
> from a stock Postfix 2.6.5:
>
> ,----[ man 5 access ]
> | FILTER transport:destination
> | After the message is queued, send the entire message through the
> | specified external content filter. The transport:destination
> | syntax is described in the transport(5) manual page.

I'll remove that reference.

Wietse
>
> ,----[ man 5 transport ]
> | A non-null transport field with a null nexthop field resets the nexthop
> | information to the recipient domain.
> `----
>
> If my question is answered in other parts of the documentation, I
> apologize in advance.
>
>
> Stefan
>
>

 |  Next  |  Last
Pages: 1 2
Prev: SOLVED Re: gssapi sasl authentication
Next: The method behind the madness