Differences between revisions 2 and 3
Revision 2 as of 2004-05-03 19:25:29
Size: 868
Editor: ip68-4-10-228
Comment:
Revision 3 as of 2009-09-20 23:16:24
Size: 870
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:
First of all, SA expects to find the names, HELO data, and IP addresses used in the SMTP transaction in the top-most Received header. If the gateway code doesn't add at least a pseudo-header containing this data, SA will not perform lookups correctly. See [http://bugzilla.spamassassin.org/show_bug.cgi?id=2860 bug 2860] for a case where a sendmail 'milter' apparently did not provide this info, resulting in false positives. First of all, SA expects to find the names, HELO data, and IP addresses used in the SMTP transaction in the top-most Received header. If the gateway code doesn't add at least a pseudo-header containing this data, SA will not perform lookups correctly. See [[http://bugzilla.spamassassin.org/show_bug.cgi?id=2860|bug 2860]] for a case where a sendmail 'milter' apparently did not provide this info, resulting in false positives.

Notes for MTA-Integration Developers

If you're calling SpamAssassin from inside an MTA or a gateway that performs scans during the SMTP transaction, you need to watch out for some slight differences in how SA needs to be called.

First of all, SA expects to find the names, HELO data, and IP addresses used in the SMTP transaction in the top-most Received header. If the gateway code doesn't add at least a pseudo-header containing this data, SA will not perform lookups correctly. See bug 2860 for a case where a sendmail 'milter' apparently did not provide this info, resulting in false positives.

Also, for some of the newer anti-spam schemes, we also need to know what the 'envelope sender' of the mail was -- see EnvelopeSenderInReceived. If you can pass this data in as well, that helps ;)

MtaIntegrationDevNotes (last edited 2009-09-20 23:16:24 by localhost)