[email protected]:
> Am 12.11.2014 um 16:04 schrieb Wietse Venema:
> > I'm considering a design for BCC support in header/body_checks
> > that works in two stages:
> >
> > - The first stage happens while an email message is received: build
> > a list of recipients in header/body_checks BCC actions, suppressing
> > duplicates on-the-fly.
> >
> > - The second stage happens after the complete message and envelope
> > are stored: add the BCC recipients to the queue file.
> >
> > The header/body_checks syntax would look like this:
> >
> > /pattern/ BCC [email protected]
> > /pattern/ BCC [email protected] NOTIFY=none [email protected]
> >
> > (for consistency, BCC recipients with NOTIFY and ORCPT attributes
> > should also be supported in access maps, sender_bcc_maps,
> > recipient_bcc_maps, and always_bcc)
>
> if i understand that correctly it would mean "smtp_header_checks" could
> have a rule like below, so if the milter added a [SPAM] prefix to the
> subject a copy of the (via smtp-transport) outgoing message could go to
> "[email protected]" for analyze and manual bayes training?
>
> /^Subject: \[SPAM\].*/ BCC [email protected]
>
> that would be *great*
The above is for RECEIVING mail. For example it could be used in
header_checks while receiving mail from a spam filter, or in
milter_header_checks while receiving header updates from a Milter.
Doing this while DELIVERING mail is fundamentally wrong: changing
a Postfix queue file is forbidden once the message is queued. The
only allowed changes are in-place updates that flag a record as
"completed".
Wietse
