On Wednesday 16 November 2011 10:06:36 Solar Designer wrote:
> On Wed, Nov 16, 2011 at 09:36:21AM -0600, Noel Jones wrote:
> > If you need more fine-grained control, use eg. SpamAssassin.
>
> I don't feel that whitelisting of PGP-encrypted messages is more
> fine-grained than the kind of blacklisting currently supported in
> header_checks and body_checks.
>
> SpamAssassin in particular is too heavy for this trivial task and
> machine (256 MB RAM, which is enough for this machine's purpose).
> I simply want to define a fairly trivial policy on what's accepted
> and what's rejected. The enhancements that I proposed would be
> sufficient.
>
> > State, including what message the line belongs to, is not saved
> > between lines.
> >
> > Adding any kind of whole-message action would require major
> > changes to the way cleanup works, and is unlikely to happen
> > anytime soon.
>
> I admit I'm not familiar with the code and I haven't tried to
> implement ACCEPT yet, but aren't DISCARD and REJECT also
> whole-message actions? Is ACCEPT somehow very different?
Yes. What do you think this ACCEPT action would do, unconditionally
permit the mail regardless of other reject actions elsewhere? This
isn't possible given Postfix design.
A permit action only applies in the context where called. A permit
result in smtpd_client_restrictions has no influence over what might
happen in smtpd_recipient_restrictions, for example.
A single reject action anywhere before acceptance causes the mail to
be rejected. Numerous permit (or dunno) actions are required for
acceptance; one per restriction stage, one per each header evaluated
in header_checks(5), one for each line in body_checks(5).
If you really think this is worth pursuing, you should consider either
content filtering (inefficient, not safe) or a different MTA.
--
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header
