On 16 Jun 2018, at 16:00 (-0400), J Doe wrote:
Hi everyone,
Thank you for the feedback. I am still uncertain, however, if I have
to explicitly define the trusted_networks/internal_networks parameters
manually in my case (where SA is running on same host as MTA) ?
Ignoring the --debug I note that --lint does warn if I manually
specify my MTA here and implies that the IP of the MTA that SA is
running on is automatically added to this list.
I note though that man Mail::SpamAssassin::Conf under the
trusted_networks setting says:
"MXes for your domain(s) and internal relays should _also_ be
specified using the "internal_networks” setting . . . “
In the same section the algorithm that is used when neither
trusted_networks or internal_networks are specified is listed, but
there’s no information about whether SA automatically grabs the IP
address of the host it is running on when that host also is the MTA.
The documentation says nothing about any automatic inclusions other than
the loopback addresses because the code does no automatic inclusions
other than the loopback addresses.
The reason for SA to NOT include anything automatically other than the
loopback addresses is that it may not be running on the same host as the
MTA or in the same IP environment even if it is on the same host. The
address lists aren't relative to were SA runs, but relative to the
MTA(s) that write Received headers which are seen by SA. So in addition
to the circumstance where a central spamd on one host is getting
submissions from multiple clients that use spamc, it is possible to use
containers and container-like mechanisms (e.g. FreeBSD jails) to isolate
spamd or a SA-embedding program like MIMEDefang or AmavisD in an
environment where it is talking to a local MTA but cannot see the
network interfaces the MTA sees.
My question is:
1. Do I have to manually specify trusted_networks and
internal_networks to list the IPv4/IPv6 address of my MTA or because
SA is running on the same host as the MTA this is automatically picked
up ?
You need to explicitly specify any addresses you want to be in those
lists other than 127.0.0.0/8 and ::1. The only reason the loopbacks are
automatically included is that an MTA is assumed to have a single
trustworthy identity: if the MTA says mail came from the loopback, it is
receiving mail from itself.
A SIDE QUESTION - is there a way, like postconf, to dump the
parameters that SA is using when it has already parsed local.cf and is
running ?
You are mistaken: Postfix's postconf command does not do that. Really,
I've read the code. It uses the same code that master and the other
Postfix programs use to parse the config files but it cannot tell you
what the running Postfix programs are currently using as their config.
If you run 'postfix reload' (or stop and start) and 'postconf' with no
changes to the config files between running them, the operative config
and the displayed config will be identical.
SpamAssassin does not have an equivalent command to postconf. The reason
for that is pragmatic: the SA "config" is huge and not entirely
reversible into a canonical unparsed config file-like format that can be
readily understood by a user. In the form dumped by the Perl debugger,
the object representing the fully parsed config is scores of thousands
of lines with megabytes of content, and that doesn't include the bits of
code generated at parse time from some rules.
You can get something like a useful dump of the non-rule config elements
with this one-liner, if all of your config files are in
/etc/mail/spamassassin/:
egrep -hvr
'^(($|[[:space:]]*$|[[:space:]]*#|#)|[[:space:]]*(score|describe|meta|tflags|(mime|)header|body|rawbody|full|uri|if|ifplugin|else|askdns|endif)[[:space:]]*)'
/etc/mail/spamassassin/*.{pre,cf}
Thanks again,
- J
--
Bill Cole
[email protected] or [email protected]
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Currently Seeking Steadier Work: https://linkedin.com/in/billcole
