From: Ronald F. Guilmette (rfgmonkeys.com)
Date: Fri Dec 01 2006 - 15:25:54 CST

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

I think that it would be Nice to be able to construct a Postfix
policy server that would refer to files (e.g. whitelists, specialized
settings, and so forth) that are specific to the relevant local
recipient for each incoming message. For example, a given local
user might have a file called ${HOME}/.whitelist.db which would be
a data base file containing a whitelist of everybody that user has
himself/herself sent e-mail to in the past. Or the user might have
a file called ${HOME}/.mail-settings.txt which might indicate things
like how agressive to be in filtering spam.

But I see a potential problem that might perhaps get in the way of
the policy server doing this sort of thing.

The question is: Given the policy server protocol, as described in
the SMTPD_POLICY_README document, what exactly is the meaning of
the value that will be passed to the policy server as the value of
the recipient= attribute? Is that the raw value, as parsed out of
the RCPT TO: command, and before any local aliasing transformations
have been applied? Assuming so, then there's a problem.

For example, here at monkeys.com, I have both "root" and "postmaster"
aliased to the local (actual) user account called "admin". So whereas
normally, my hypothetical end-luser configurable Postfix policy server,
when given a name=value pair such as:

        recipient=rfgmonkeys.com

would know to go and look for a file called ~rfg/.mail-settings.txt,
and to then read that in order to determine other aspects of the
policy server's behavior... based upon rfg's personalized preferences...
this simple scheme will break down as soon as there is an incoming
message that's addressed to <postmastermonkeys.com>, because there
ain't actually any such local user account as "postmaster", and thus,
there ain't no such home directory as ~postmaster.

The bottom line is that I think the policy server protocol might
benefit from an enhancement which would cause _both_ the pre- and
post-aliased recipient addresses for the current message to be passed
to the policy server. So, for example, the policy server might be
passed:

        ...
        recipient=postmastermonkeys.com
        rewritten_recipient=adminmonkeys.com
        ...

where the recipient= value is the recipient address as it exists _before_
any address rewriting (e.g. local alias processing) and where the
rewritten_recipient= value would be the recipient address _after_ local
address rewriting.

If that (small?) change to the protocol were made, I think that it would
greatly facilitate everyone's ability to construct Postfix policy servers
that include the capability to have the behavior of those policy servers
tailored to the needs and desires of each separate and independent local
user account, including those that may routinely be sent mail via various
aliases.

Obviously, Postfix already has all of the built-in brains and smarts to
know how to do all of the fancy things it can do, and does do, as regards
to rewriting addresses. Personally, I don't want to re-invent this wheel.
I sure as heck don't want to even begin to try to reproduce all of that
well-tested Postfix code and logic in my own separate and external policy
server. Instead I'd very much like it if Postfix were just to do what it
is going to do anyway (i.e. recipient address rewriting) and then pass its
results out to my policy server. In addition to saving me one hell of a
lot of work, this approach would also insure that there won't be any "skew"
between Postfix and the external policy server, i.e. it eliminates the
possibility of them each trying to do recipient address rewriting, and
then having these two separate tools come up with two different and non-
identical final/rewritten results.

Regards,
rfg

P.S. It is not too hard to envision a use also for a rewritten_sender=
parameter in the policy server protocol too. But for me personally, I
have no real need for that at the moment. I do feel sure however that
I could make very good use of a rewritten_recipient= protocol enhancement,
such as I have described above.

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]