Bug 3166

Summary: RFE: out-of-band channel for plugins in spamd protocol headers
Product: Spamassassin Reporter: Martin Kutschker <martin.t.kutschker>
Component: spamc/spamdAssignee: SpamAssassin Developer Mailing List <dev>
Status: NEW ---    
Severity: enhancement CC: parkerm
Priority: P5    
Version: 2.63   
Target Milestone: Future   
Hardware: All   
OS: All   
Whiteboard:

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).