On 15 Jan 2019, at 14:24, Grant Taylor wrote: > On 01/15/2019 11:39 AM, Bill Cole wrote: >> This strikes me as a flaw in whatever milter you're using. Some (e.g. >> MIMEDefang) milters deal with the fact that they don't get a local Received >> header by constructing one from what they know before passing the message to >> SA. > > The SPF milter is constructing the header. I assume that it's doing so > properly. At least the headers I see coming out of the MTA are correct. > > I think that SpamAssassin is looking for a header that isn't there yet. - > Both SpamAssassin and my SPF filter are hooked into the same MTA as milters. > So both of them see the message before it's accepted and all headers new are > added. > > I don't know if the SPF milter can add the header sooner, or if that is > controlled by the MTA. > > I would also like SpamAssassin to use the information available to it via the > milter interface instead of relying on a header.
Let me clarify... There are at many different milters that can use SpamAssassin listed at https://wiki.apache.org/spamassassin/IntegratedInMta#Integrated_into_Sendmail. Some links there may be dead. SpamAssassin is not a milter. SpamAssassin knows nothing about message parameters passed through the milter interface between a MTA and a milter. The ONLY message data that SpamAssassin knows about is what it gets in a RFC822/2822/5322 format message with parseable headers. A milter that uses SpamAssassin can modify the message that it receives via the milter interface before passing it to SpamAssassin for analysis. This allows the milter to inform SpamAssassin of facts that SpamAssassin can use, such as the SMTP client address, envelope sender and recipients, and whatever else it gets from the MTA. For SpamAssassin to do SPF calculations it needs to have a Received header and envelope sender, which can be embedded in headers that are added by a milter that uses SpamAssassin.
signature.asc
Description: OpenPGP digital signature
