Bug 4194 - X-Spam-Relays-* needs "for" sub-field
Summary: X-Spam-Relays-* needs "for" sub-field
Status: RESOLVED WONTFIX
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Rules (show other bugs)
Version: 3.0.2
Hardware: All Linux
: P3 enhancement
Target Milestone: Future
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-03-16 02:05 UTC by Eric A. Hall
Modified: 2018-01-29 01:18 UTC (History)
3 users (show)


Attachment Type Modified Status Actions Submitter/CLA Status
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
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?
Comment 5 Dave Jones 2018-01-28 18:53:23 UTC 
EnvTo is not going to be available all of the time to all SA instances that aren't running as a milter directly on the MTA.  For example, I run MailScanner which won't have access to this so I solve it with other milters like postfwd.

After 13 years, this issue should probably be closed.
Comment 6 Bill Cole 2018-01-29 01:18:31 UTC 
The core need is better addressed via glue layers (amavisd-new, MIMEDefang, wrapper scripts feeding spamc, etc.) and/or MTA-generated headers. Those are more reliable than SA parsing Received headers for information which may or may not be present there.