>From Justin Mason:
| yeah. I would probably add a new arg for "metadata headers", e.g.
| (data => [EMAIL PROTECTED], add_From_line => 0,
| metadata => { 'X-Envelope-To' => '<[EMAIL PROTECTED]', ... });
| which SpamAssassin just mixes in with the real headers internally.
Merging 'meta information' with headers may be ok as a quick solution
to take advantage of existing mechanisms for header processing,
but there are good reasons why p1 (envelope) and p2 (header)
information are two separate channels in mail transport.
For example, if some day envelope address could be used for
white/blacklisting, you would have to ensure that some X-Envelope-To:
inserted by spammer would not take precedence over the X-Envelope-To:
inserted by local MTA. It is not a clean solution to first merge
two independent channels into one, only to have to split them again
by some educated guessing algorithm.
From: Nancy McGough
| You might also want to set up SA to look for
| Delivered-To: X-Delivered-To: Envelope-To:
| X-Original-To: X-Rcpt-To: X-Real-To:
| <http://www.ii.com/internet/robots/procmail/qs/#envelope>
...another reason to not give meta information the form of a header field.
It is ok to _copy_ meta information as extra header fields _into_ the
mail header, but it should also be kept and made available separately
for cases where such information is relied on, e.g. when someone would
decide to call local delivery agent from SA, or to use it for
white/blacklisting.
Mark
-------------------------------------------------------
This SF.NET email is sponsored by: eBay
Great deals on office technology -- on eBay now! Click here:
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
_______________________________________________
Spamassassin-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
