Bug 3166 - RFE: out-of-band channel for plugins in spamd protocol headers
Summary: RFE: out-of-band channel for plugins in spamd protocol headers
Status: NEW
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: spamc/spamd (show other bugs)
Version: 2.63
Hardware: All All
: P5 enhancement
Target Milestone: Future
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-03-13 03:03 UTC by Martin Kutschker
Modified: 2009-08-21 11:49 UTC (History)
1 user (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 Martin Kutschker 2004-03-13 03:03:00 UTC 
Add new 'headers' to the protocol that contain SMTP protocol data:

Client IP and hostname
SMTP HELO response
Envelope From
Envelope To

This data may be used eg when connecting to dccifd, which uses this values for
its own protocol.

see http://www.dcc-servers.net/dcc/dcc-tree/dccifd.html (Protocol)

spamd might get these values either eg when used from a Sendmail milter or a
custom Sendmail mailer (contact me if you want to know how it's done for the
webmailer www.blackbox.net).
Comment 1 Daniel Quinlan 2005-03-30 01:09:08 UTC 
move bug to Future milestone (previously set to Future -- I hope)
Comment 2 Michael Parker 2006-08-02 04:06:56 UTC 
Just a quick though, we could possibly add a header to the spamd protocol that
would then populate metadata for a message.  Then a plugin could do whatever it
wanted with that data.

Might even be able to do a simple plugin hook in spamd to catch this additional
header and do something with it.
Comment 3 Justin Mason 2006-08-02 09:44:54 UTC 
'Client IP and hostname
SMTP HELO response
Envelope From
Envelope To'

note that all of those items of data are supposed to be put into a Received
header by the milter before passing to SA.  I think this is documented on the
wiki somewhere.... ;)

'we could possibly add a header to the spamd protocol that
would then populate metadata for a message.  Then a plugin could do whatever it
wanted with that data. Might even be able to do a simple plugin hook in spamd to
catch this additional header and do something with it.'

that sounds sensible, although I'd really need to see some good use cases to
ensure it really is the appropriate fix for those problems...
Comment 4 Justin Mason 2006-12-15 08:10:29 UTC 
retitling to reflect Michael's idea, since the SMTP protocol data is better
preserved in the scanned message's headers, as documented
Comment 5 Mark Martinec 2009-08-21 08:13:52 UTC 
See also a partial solution in Bug 6088,
and a related problem in Bug 4469 (checking large messages).