>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