|Summary:||X-Spam-Relays-* needs "for" sub-field|
|Product:||Spamassassin||Reporter:||Eric A. Hall <eric.hall>|
|Component:||Rules||Assignee:||SpamAssassin Developer Mailing List <dev>|
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 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?