I have caught up on the previous discussion of Sep 20 re the
policyd. Has there been any news subsequent to that
discussion?

On Fri, Oct 05, 2001 at 05:11:32PM -0400, Wietse Venema wrote:
| > Adding an access check keyed on $LOGNAME would make it
| > possible for an external governor daemon put an entry in a
| > mysql lookup table to say "exceeded outbound message quota"
| > once it had seen more than, say, 60 recipients per hour with
| > the same sender.
|
| What about the potential for abuse. If I send a lot of junk mail
| in your name will you be blocked from sending mail?

We'll have to solve this using SASL. Also maildrop should
record the uid of the sender --- I'm not sure if it does.

| Whatever :-) One has to bear in mind that it introduces another
| point of failure - if the policy daemon breaks no mail will get
| through.

If the postfix-standard policyd doesn't stray too far from
the existing uce restriction class architecture where all
processing is done inside postfix we can't go too far wrong.
People who implement their own policyds know what they're in
for.

At worst the master can keep track of the policyd's status
and, after a timeout, change the 4xx default to accept.

| > If we make uced an externally specifiable pipe agent, this
| > begins to look like content filtering.
|
| There is a problem if we mix header/body restrictions with SMTP
| restructions, and that is that Postfix will sometimes have to
| receive the entire message before it can reject it. This
| complicates things.
|

Yes, sometimes postfix will have to do that. But with a
policyd continually responding to smtpd with either "ok so
far, keep going" or "reject 4xx with reason ..." it becomes
much simpler for smtpd to respond to the client.

-
To unsubscribe, send mail to majordomopostfix.org with content
(not subject): unsubscribe postfix-users

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