Bug 4194

Summary: X-Spam-Relays-* needs "for" sub-field
Product: Spamassassin Reporter: Eric A. Hall <eric.hall>
Component: RulesAssignee: SpamAssassin Developer Mailing List <dev>
Status: NEW ---    
Severity: enhancement CC: hege
Priority: P3    
Version: 3.0.2   
Target Milestone: Future   
Hardware: All   
OS: Linux   
Whiteboard:

Description Eric A. Hall 2005-03-16 02:05:33 UTC
My plugin has the ability to look for black/whitelist scores against a variety
of addresses and domains. One thing I would like to include here is the envelope
recipient (the "RCPT TO" address). The only place this data is provided to SA
(normally) is in the "for" sub-field of the Received header. I would like to be
able to read this data via the X-Spam-Relays-Untrusted header (so that I can add
in a blacklist score), and am therefore requesting that this sub-field be added
to that psuedo-header.
Comment 1 Eric A. Hall 2005-03-16 02:10:53 UTC
ps--forgot to mention that this sub-field is usually only present in the
Received header if only one recipient was listed in the envelope exchange. Since
the sub-field does not provide for arrays, and it is best not to provide
incomplete information, most implementations only provide this data if there was
just one recipient. It's still useful, however, when it is actually there.

Something for future consideration may be to provide an LMTP wrapper interface
to the SA engine, and then you can provide the full array of envelope recipient
addresses, since you will get the full list.
Comment 2 Adam Katz 2011-03-14 15:06:19 UTC
related to bug 4195
Comment 3 Mark Martinec 2011-03-22 22:25:58 UTC
> Something for future consideration may be to provide an LMTP wrapper interface
> to the SA engine, and then you can provide the full array of envelope recipient
> addresses, since you will get the full list.

It is already done, it is called amavisd-new and does just that:
provides SMTP or LMTP interface on both ends, and passes out-of-band
envelope information (sender and a list of recipients) to SpamAssassin,
which can be accessed by plugins or elsewhere. Think of it as a spamd
with a different interfacing protocol.
Comment 4 Henrik Krohns 2011-05-02 07:34:40 UTC
You can make rules to MTA specific headers like X-Original-To, X-Envelope-To, Apparently-To etc... see PerMsgStatus.pm all_to_addrs(). I doubt we will be implementing "EnvelopeTo" heuristics.

Then again lots of info is parsed from Received headers, so I'm not sure why "envto" could not be included.. possibly helping Bayes?