Re: Question regarding trusted_networks
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
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Currently Seeking Steadier Work: https://linkedin.com/in/billcole
Re: Question regarding trusted_networks
On Sat, 16 Jun 2018 16:00:05 -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) ? You shouldn't need to set network settings, unless you want to extend your trusted network or internal+trusted into a third party network or need to workaround a rare situation or bad practice. Despite the warning I wouldn't recommend setting the networks unless you have good reason. SA is pretty good at working this stuff out, but once you set it it manually it's your responsibly. If you want to scan outgoing mail, make sure that that your mta is recording authentication on submission e.g. showing "with ESMTPA", rather than "with ESMTP". > 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. Aside from the practicalities of that, it shouldn't need to. Remember that a received header reports the upstream IP address.
Re: A question about DCC and learning.
On Fri, 15 Jun 2018 16:24:46 +0300 Reio Remma wrote: > Hello! > > I'm curious, if I turn on DCC learning, does it learn with both the > learn and report options to sa-learn or only report? There are two types of DCC test, most people only use the free version which is purely a bulk mail test. Bulk mail is determined by how often each checksum has been queried, not by how often it's reported.
Re: MISSING_SUBJECT
On Wed, 13 Jun 2018 16:36:02 -0700 (PDT) John Hardin wrote: > On Tue, 12 Jun 2018, micah anderson wrote: > > > I had a message marked with: > > > > 2.3 EMPTY_MESSAGE Message appears to have no textual parts and no > > Subject: > > > > It did not have a subject, but it did have content (although only > > encrypted) > > It may not be considering an encrypted message part to be a text body > part. What was the MIME type of that part? The rule is: meta EMPTY_MESSAGE !__MIME_ATTACHMENT && !__NONEMPTY_BODY where body __NONEMPTY_BODY /\S/ i.e. it's looking for an attachment or body text. It needs to be something like: !__MIME_ATTACHMENT && !__NONEMPTY_BODY && !ENCRYPTED_MESSAGE ENCRYPTED_MESSAGE already exists.
Re: Question regarding trusted_networks
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. 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 ? 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 ? Thanks again, - J
Re: Question regarding trusted_networks
Matus UHLAR - fantomas skrev den 2018-06-16 16:37: not external networks. only external mail servers you trust not to forge e-mail headers. They may send spam but are not the spam sources. not correct spamassassin need to know all wan ips your own servers use, it does not need to protect forgin senders ips or even trustness of forgin spf is a better forgin protector
Re: Question regarding trusted_networks
Matus UHLAR - fantomas skrev den 2018-06-16 18:07: On 16.06.18 10:12, David Jones wrote: That is basically the same thing worded a little differently. If you have an internal mail relay and your SA server has a private IP on it, then that will be an RFC 1918 IP or range in your internal_networks. the differences it that RFC1918 networks should NOT be listed in internal_networks - only mail servers should be listed, no clients. there is no point in have non routeble ips tested by rbls thats why 127.0.0.1 is forced (RFC 1700) but adding RFC1918 does not hurt at all there is alot of ipv6 ranges to add aswell pleasee understand what it does
Re: Question regarding trusted_networks
On 06/15/2018 05:44 PM, J Doe wrote: Jun 15 18:39:23.422 [8422] dbg: config: trusted_networks are not configured; it is recommended that you configure trusted_networks manually My question is: — Should I manually set trusted_networks to have the IP address of the host it is running on and ignore the warning from --lint or … — Should I not set trusted_networks and ignore the warning from --debug ? On 16.06.18 06:33, David Jones wrote: internal_networks should be any RFC 1918 networks that your mail server sees plus any public networks that are in your control. On 06/16/2018 09:37 AM, Matus UHLAR - fantomas wrote: no. only servers that deliver mail to you, as your MX servers or other mailservers directly within your organization should be in internal_networks. On 16.06.18 10:12, David Jones wrote: That is basically the same thing worded a little differently. If you have an internal mail relay and your SA server has a private IP on it, then that will be an RFC 1918 IP or range in your internal_networks. the differences it that RFC1918 networks should NOT be listed in internal_networks - only mail servers should be listed, no clients. Mail with all Received headers of IPs within the internal_networks will hit the ALL_TRUSTED rule. ALL_TRUSTED uses trusted_networks, not internal_networks. listing internal and external clients in trusted_networks is fine, but they don't belong to internal_networks. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Saving Private Ryan... Private Ryan exists. Overwrite? (Y/N)
Re: confirm unsubscribe from users@spamassassin.apache.org
Thanks for helping. Bruce ser...@megavoice.com Quoting users-h...@spamassassin.apache.org: Hi! This is the ezmlm program. I'm managing the users@spamassassin.apache.org mailing list. To confirm that you would like ser...@megavoice.com removed from the users mailing list, please send a short reply to this address: users-uc.1529162638.lngocjclkimmgbgggeff-server=megavoice@spamassassin.apache.org Usually, this happens when you just hit the "reply" button. If this does not work, simply copy the address and paste it into the "To:" field of a new message. I haven't checked whether your address is currently on the mailing list. To see what address you used to subscribe, look at the messages you are receiving from the mailing list. Each message has your address hidden inside its return path; for example, m...@xdd.ff.com receives messages with return path: -mary=xdd.ff@spamassassin.apache.org. Some mail programs are broken and cannot handle long addresses. If you cannot reply to this request, instead send a message to and put the entire address listed above into the "Subject:" line. --- Administrative commands for the users list --- I can handle administrative requests automatically. Please do not send them to the list address! Instead, send your message to the correct command address: To subscribe to the list, send a message to: To remove your address from the list, send a message to: Send mail to the following for info and FAQ for this list: Similar addresses exist for the digest list: To get messages 123 through 145 (a maximum of 100 per request), mail: To get an index with subject and author for messages 123-456 , mail: They are always returned as sets of 100, max 2000 per request, so you'll actually get 100-499. To receive all messages with the same subject as message 12345, send a short message to: The messages should contain one line or word of text to avoid being treated as sp@m, but I will ignore their content. Only the ADDRESS you send to is important. You can start a subscription for an alternate address, for example "john@host.domain", just add a hyphen and your address (with '=' instead of '@') after the command word: To stop subscription for this address, mail: In both cases, I'll send a confirmation message to that address. When you receive it, simply reply to it to complete your subscription. If despite following these instructions, you do not get the desired results, please contact my owner at users-ow...@spamassassin.apache.org. Please be patient, my owner is a lot slower than I am ;-) --- Enclosed is a copy of the request I received. Return-Path: Received: (qmail 36825 invoked by uid 99); 16 Jun 2018 15:23:58 - Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 16 Jun 2018 15:23:58 + Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 7E8DD180848 for ; Sat, 16 Jun 2018 15:23:58 + (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 0.754 X-Spam-Level: X-Spam-Status: No, score=0.754 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_NUMERIC_HELO=0.865, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=megavoice.com Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id YhHQBEleHlFM for ; Sat, 16 Jun 2018 15:23:57 + (UTC) Received: from host.megavoice.com (host.megavoice.com [72.52.144.114]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 72FF75F1B9 for ; Sat, 16 Jun 2018 15:23:57 + (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=megavoice.com; s=default; h=MIME-Version:Content-Type:Subject:To:From: Message-ID:Date:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=m/nusfs+J2T3VGxMz2Xy5TE1Kf q1xaQhLh94fmCSDtgMV5HShNSCqFKWQq0UFy11IsncWk4XPds59OpkTyXGXDIO6/A6j1eaav1T/8r HIN1CI9aLcVP51pjsBbtSU8+aTQ1ic6ruJ1EYp/raQx5QAM/soXRw+cbflH/GpvEexYEuO1ooVHs7 6dlLaPeaDNnlli5tsntCB60Lv6z90IKYZhhB/vN9u6agKmm+d3IEhIl5my2CrtXrN9fMMqrHnMgwI jDySNVqR74o6qWjy2FEptuGapu3e3v8G1owBIihxMZ+BbR9W6VqNyGJEuD/axpb5/6TncqpInZzRS Ll6DYiKg==; Received: from [::1]
Re: Question regarding trusted_networks
On 06/16/2018 09:37 AM, Matus UHLAR - fantomas wrote: On 06/15/2018 05:44 PM, J Doe wrote: Jun 15 18:39:23.422 [8422] dbg: config: trusted_networks are not configured; it is recommended that you configure trusted_networks manually My question is: — Should I manually set trusted_networks to have the IP address of the host it is running on and ignore the warning from --lint or … — Should I not set trusted_networks and ignore the warning from --debug ? On 16.06.18 06:33, David Jones wrote: internal_networks should be any RFC 1918 networks that your mail server sees plus any public networks that are in your control. no. only servers that deliver mail to you, as your MX servers or other mailservers directly within your organization should be in internal_networks. That is basically the same thing worded a little differently. If you have an internal mail relay and your SA server has a private IP on it, then that will be an RFC 1918 IP or range in your internal_networks. If your SA servers only have public IPs on them, then you won't have any RFC 1918 IPs in the internal_networks but you may have 127.0.0.1 and fe80::/10 for locally generated email plus any public ranges that smarthost to you. In my case, I have many customers setup to smarthost to smtp.ena.net so I have many large CIDRs in my Postfix mynetworks and SA internal_networks. This can be very different for each use case and probably deserves a drawing to explain it better. Seems like I have seen a graphic or something that shows the logic behind this setting. Mail with all Received headers of IPs within the internal_networks will hit the ALL_TRUSTED rule. trusted_networks should be internal_networks plus any external networks that you trust to not send spam -- in other words they are known to have their own outbound mail filtering. This will tell SA to go back one more Received: header to test for "last_external" checks and RBL checks. not external networks. only external mail servers you trust not to forge e-mail headers. They may send spam but are not the spam sources. True. That is a better way to put it. I have read that in the SA wiki documentation now that you mention it. -- David Jones
Re: Question regarding trusted_networks
On 06/15/2018 05:44 PM, J Doe wrote: Jun 15 18:39:23.422 [8422] dbg: config: trusted_networks are not configured; it is recommended that you configure trusted_networks manually My question is: — Should I manually set trusted_networks to have the IP address of the host it is running on and ignore the warning from --lint or … — Should I not set trusted_networks and ignore the warning from --debug ? On 16.06.18 06:33, David Jones wrote: internal_networks should be any RFC 1918 networks that your mail server sees plus any public networks that are in your control. no. only servers that deliver mail to you, as your MX servers or other mailservers directly within your organization should be in internal_networks. trusted_networks should be internal_networks plus any external networks that you trust to not send spam -- in other words they are known to have their own outbound mail filtering. This will tell SA to go back one more Received: header to test for "last_external" checks and RBL checks. not external networks. only external mail servers you trust not to forge e-mail headers. They may send spam but are not the spam sources. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. It's now safe to throw off your computer.
Re: MISSING_SUBJECT
On 15.06.18 09:04, Matus UHLAR - fantomas wrote: On Tue, 12 Jun 2018, micah anderson wrote: I had a message marked with: 2.3 EMPTY_MESSAGE Message appears to have no textual parts and no Subject: It did not have a subject, but it did have content (although only encrypted) John Hardin writes: It may not be considering an encrypted message part to be a text body part. What was the MIME type of that part? On 14.06.18 12:17, micah anderson wrote: pgp/mime and wat is an attachment or just the e-mail came with mime type pgp/mime;2~? OK, again: was it an attachment or just the e-mail came with mime-type PGP/mime ? please show us headers of that message (pastebin for example) -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. "One World. One Web. One Program." - Microsoft promotional advertisement "Ein Volk, ein Reich, ein Fuhrer!" - Adolf Hitler
Re: Question regarding trusted_networks
On 06/16/2018 06:33 AM, David Jones wrote: On 06/15/2018 05:44 PM, J Doe wrote: Hello, I am currently using SpamAssassin 3.4.1 on Ubuntu Linux 16.04.4 LTS. I have SA running on a server with Postfix as the MTA on the same server. I have a question regarding the trusted_networks configuration parameter (man Mail::SpamAssassin::Conf). I manually added this to a custom local.cf file and linted it: /etc/spamassassin/local.custom.cf: trusted_networks 1.2.3.4 $ spamassassin --lint --config-file=/etc/spamassassin/local.custom.cf This displays: Jun 15 18:31:02.893 [8327] warn: netset: cannot include 1.2.3.4/32 as it has already been included This lead me to believe that when SpamAssassin loads, it automatically adds the IP address of the host it is running on (along with localhost, which is mentioned in man). As a result, I removed the trusted_networks entry and a subsequent lint produces no warnings or errors. When I then ran lint and added the --debug flag: $ spamassassin --debug --lint --config-file=/etc/spamassassin/local.custom.cf …I see the following in the output: Jun 15 18:39:23.422 [8422] dbg: config: trusted_networks are not configured; it is recommended that you configure trusted_networks manually My question is: — Should I manually set trusted_networks to have the IP address of the host it is running on and ignore the warning from --lint or … — Should I not set trusted_networks and ignore the warning from --debug ? Thanks, - J internal_networks should be any RFC 1918 networks that your mail server sees plus any public networks that are in your control. trusted_networks should be internal_networks plus any external networks that you trust to not send spam -- in other words they are known to have their own outbound mail filtering. This will tell SA to go back one more Received: header to test for "last_external" checks and RBL checks. For example: internal_networks 192.168.0.0/16 fe80::/10 96.4.0.0/15 207.191.176.0/20 trusted_networks 192.168.0.0/16 fe80::/10 96.4.0.0/15 207.191.176.0/20 162.216.126.0/23 My SA servers actually have public IPs on them so technically I don't need the 192.168.0.0/16 in the list but I put it in there for reference. If your mail servers are NAT'd and have a private RFC 1918 IP on them then you need to include any internal subnet that can send outbound through your SA server. Oh yeh, when using Postfix your internal_networks should basically match the Postfix mynetworks value. # postconf mynetworks Then copy/paste the internal_networks to trusted_networks and add any external networks that can be trusted, if any. trusted_networks might start out identical to internal_networks until you find external sources that you want to include later. -- David Jones
Re: Question regarding trusted_networks
On 06/15/2018 05:44 PM, J Doe wrote: Hello, I am currently using SpamAssassin 3.4.1 on Ubuntu Linux 16.04.4 LTS. I have SA running on a server with Postfix as the MTA on the same server. I have a question regarding the trusted_networks configuration parameter (man Mail::SpamAssassin::Conf). I manually added this to a custom local.cf file and linted it: /etc/spamassassin/local.custom.cf: trusted_networks 1.2.3.4 $ spamassassin --lint --config-file=/etc/spamassassin/local.custom.cf This displays: Jun 15 18:31:02.893 [8327] warn: netset: cannot include 1.2.3.4/32 as it has already been included This lead me to believe that when SpamAssassin loads, it automatically adds the IP address of the host it is running on (along with localhost, which is mentioned in man). As a result, I removed the trusted_networks entry and a subsequent lint produces no warnings or errors. When I then ran lint and added the --debug flag: $ spamassassin --debug --lint --config-file=/etc/spamassassin/local.custom.cf …I see the following in the output: Jun 15 18:39:23.422 [8422] dbg: config: trusted_networks are not configured; it is recommended that you configure trusted_networks manually My question is: — Should I manually set trusted_networks to have the IP address of the host it is running on and ignore the warning from --lint or … — Should I not set trusted_networks and ignore the warning from --debug ? Thanks, - J internal_networks should be any RFC 1918 networks that your mail server sees plus any public networks that are in your control. trusted_networks should be internal_networks plus any external networks that you trust to not send spam -- in other words they are known to have their own outbound mail filtering. This will tell SA to go back one more Received: header to test for "last_external" checks and RBL checks. For example: internal_networks 192.168.0.0/16 fe80::/10 96.4.0.0/15 207.191.176.0/20 trusted_networks 192.168.0.0/16 fe80::/10 96.4.0.0/15 207.191.176.0/20 162.216.126.0/23 My SA servers actually have public IPs on them so technically I don't need the 192.168.0.0/16 in the list but I put it in there for reference. If your mail servers are NAT'd and have a private RFC 1918 IP on them then you need to include any internal subnet that can send outbound through your SA server. -- David Jones
