Re: How do you set nomail for the List?
On 20 Apr 2021, at 18:29, Bob Proulx wrote: > Hmm... No. I disagree. It's not if-one-then-the-other. All that is > needed to disprove it is one example. And as it happens I can list > two immediately. Which does nothing to disprove "most mailing list require subscription" which is absolutely true. -- The omnipotent eyesight of various supernatural entities is often remarked upon. It is said that they can see the fall of every sparrow. And this may be true. But there is only one who is always there when it hits the ground. --Hogfather
Re: How do you set nomail for the List?
Antony Stone wrote: > Bob Proulx wrote: > > I was not aware that this mailing list requires one to be subscribed > > to post to it. Does it? It's not necessary on most technical mailing > > lists. > > I would in fact say the exact opposite: most mailing lists do > require subscription in order to post, primarily in order to reduce > spam from random addresses. But, but, but... SpamAssassin's entire purpose is an anti-spam function! Oh the irony of it! > After all, if just anyone, without subscription, can post to a list, then > it's > open to the entire Internet, and then, as we all know, anarchy ensues... Hmm... No. I disagree. It's not if-one-then-the-other. All that is needed to disprove it is one example. And as it happens I can list two immediately. So as it happens I am actually one of the anti-spam admins for the lists.gnu.org mailing lists. There are some 1,500+ mailing lists there. Most of them are bug reporting mailing lists. Requiring people to subscribe to a mailing list in order to make a report would be much too burdensome. Therefore the bug reporting lists are open lists and anyone may post there and it does not require subscriptions. I know that many will argue that there is nothing but chaos and anarchy there but there is very little spam on the mailing lists! (If people do see spam there I welcome reports so that problem can get addressed. Send reports to the mailman AT gnu.org address please.) One of the major components of the anti-spam to those mailing lists is SpamAssassin. Plus some additional things too of course. Secondly the Debian project mailing lists are extensive and extremely active too. The Debian lists are all open lists. Anyone may post to them. Many do! I am not directly involved there but I have been a long time community participant. If we can do it then why can't SpamAssassin do it for itelf? Don't answer as that's a rhetorical question. I already know the answer. The answer is because SpamAssassin is using the Apache Software Foundation infrastructure and Apache isn't operating their mailing lists that way. The SpamAssassin group could do things differently from Apache if they wanted to do so but using the Apache infrastructure has advantages and that is why they moved under that umbrella in the first place. And closed mailing lists are just one of the trade-offs of that decision and it is okay. Bob
Re: KAM_DMARC_REJECT on internal emails
On Mon, 19 Apr 2021 20:40:58 -0400 Bill Cole wrote: > On 19 Apr 2021, at 18:25, RW wrote: > I suggested exempting messages hitting ALL_TRUSTED from > KAM_DMARC_REJECT. > Matus noted correctly that doing so with external machines in > trusted_networks could result in "problems" i.e. allowing unsigned > (i.e. fake) messages to bypass KAM_DMARC_REJECT because they are > originating on a machine which is trusted not to write bogus Received > headers. Note that a machine in trusted_networks is NOT necessarily > presumed to not originate spam. > I proposed (and have committed to my sandbox) an ALL_INTERNAL rule > which could be used to exempt mail which has originated on internal > networks Anything that enters through through the remote trusted network and hits ALL_TRUSTED will almost certainly pass whatever authentication mechanism are set-up for the domain. The difference between ALL_TRUSTED and ALL_INTERNAL will likely be small. There are minor advantages either way.
Re: How do you set nomail for the List?
On Tuesday 20 April 2021 at 23:27:14, Bob Proulx wrote: > I was not aware that this mailing list requires one to be subscribed > to post to it. Does it? It's not necessary on most technical mailing > lists. I would in fact say the exact opposite: most mailing lists do require subscription in order to post, primarily in order to reduce spam from random addresses. After all, if just anyone, without subscription, can post to a list, then it's open to the entire Internet, and then, as we all know, anarchy ensues... At least if you have to subscribe first: a) the subscription process itself is a barrier to bots b) a list admin can block unwanted posters. Antony. -- I know I always wanted to be somebody, but I guess I should have been more specific. Please reply to the list; please *don't* CC me.
Re: How do you set nomail for the List?
Antony Stone wrote: > Incidentally, I had no idea what "a pre-mangled address for the web archive > readers" meant. You are the second person to mention this, the first in a direct message to me. Which means there will be many. Sorry. Let me explain. Due to too much caution about spammers harvesting email addresses from web pages most web mailing list archives block display of anything that looks similar to an email address. I say similar because often false positives are a problem. Which is super annoying! While I am still reading email with an actual mail reader (I am using mutt) I know that the majority of all email users today are using a web-mail interface to email. And many of those people are using mailing list archives to read mailing lists. Therefore I try to write with that reading interface of those other users in mind. This web archive hiding of anything that looks like an email address makes posting email addresses in responses to people more difficult than it should be. I happen to be aware of the problem and sensitive to the breakage and therefore, when I remember to do so, I try to include both the address written plain as it should be and also encoded in the typical way for a human to be able to read it and reconstruct it back into the original. Here are some examples of my message with the email address hidden, obscured, "mangled" by the web mail readers, for the archives listed for this mailing list. So that you can see the problem that is being addressed by including both a plain email address and also a human readable but encoded address to avoid the hiding. says "[hidden email]" http://spamassassin.1065346.n5.nabble.com/How-do-you-set-nomail-for-the-List-td161302.html says "users-unsubscr...@spamassassin.apache.org" with those dots mangling it https://www.mail-archive.com/users@spamassassin.apache.org/msg108060.html says "user...@spamassassin.apache.org" again with different dots mangling it https://markmail.org/search/list:org.apache.spamassassin.users#query:list%3Aorg.apache.spamassassin.users+page:1+mid:5tjzft7smag2433m+state:results Meanwhile other archives show the message plain. https://mail-archives.apache.org/mod_mbox/spamassassin-users/202104.mbox/browser https://marc.info/?l=spamassassin-users=161893573926245=2 Sorry for perhaps obscure and confusing reference to "pre-mangling" it. I meant I was going to get ahead of the web archive manglers and do it myself so that my "pre-mangled" version would be left un-mangled and therefore still readable and possible to reconstruct. And also even though the OP was asking the question that means there are many more people who would like to know the answer to it too who are wanting to know but not wanting to ask. And some of them will use the web to search for wisdom and find one of the above email archives. If they find a good archive without mangling then they have their answer. If they find a bad archive that mangles then they are left still looking. However in this case, hopefully, my answer is still useful to them even on a bad archive as they can assemble it themselves. https://xkcd.com/979/ Hopefully that explains what I meant there! :-) Bob
Re: How do you set nomail for the List?
RW wrote:
> I think the question was getting no mail without unsubscribing and
> losing the ability to post. This is useful if you read a list by other
> means, e.g. via NNTP.
I was not aware that this mailing list requires one to be subscribed
to post to it. Does it? It's not necessary on most technical mailing
lists.
I look now at the help file for the apache.org mailing lists and do
not find any way to set a "nomail" option (which some other mailing
list management software provides). Therefore I think there is no
feature to do it. The help file only lists unsubscription. Since it
has become part of the discussion I will include the help file at the
end.
As to your specific case question I can only find this infomration on
it and it appears that primarily it requires the list owner to
manually handle things.
https://www.ezmlm.org/manual/Unsubscribing.html
1.4.1 Posting from an alternative address when post are allowed only to
subscribers.
When a list is set up to allow posts from subscribers only(*), a post
from an address ('jon...@softx.com') may be rejected since this
address is not a subscriber (even though mail to the subscriber
'j...@univ.edu' reaches you, ezmlm has no way of knowing this). The
easiest way to deal with this is to unsubscribe 'j...@univ.edu' and
subscribe 'jon...@softx.com'. If this is not possible/desirable, send
the addresses in question with a note to
'mailinglist-ow...@example.org'.
The list owner can add your sender address (in this case
'jon...@softx.com') to an extra address lists of non-subscribers
allowed to post (and access the archive). The extra addresses are
kept in a database much like subscriber addresses.
In fact, you can add the address 'jon...@softx.com' as an alias
for the list 'mailingl...@example.org' by mailing
'mailinglist-allow-subscribe-jonesj=softx@example.org' and
replying to the confirmation request. Again, you're changing the
"target" address of the request from the default (the sender
address) by adding the target to the command with the '@' replaced
by '='. Of course, the "allow" list doesn't send out posts. It is
solely a vehicle for storing "allowed" aliases.
That last paragraph (I reformated it into these paragraphs for
readability) is not clear to me and I do not understand it. But this
next makes it clear that it can only be done by an administrator.
https://www.ezmlm.org/manual/Adding-Aliases.html
2.4 Adding subscriber aliases(*).
ezmlm lists may be set up to only allow subscribers to send
messages to the list. This is less secure than moderation, but
still keeps most "garbage" off the list. Occasionally, a user may
wish to send messages from an address other than the subscription
address. As a remote administrator, you can add the user's alias
to a special "allow" database. To add 'j...@example.net' as an
alias to the 'mailingl...@example.org', send mail to
'mailinglist-allow-subscribe-john=example@example.org'. -unsubscribe
and other commands work the same way. The messages ezmlm sends
talk about the 'mailinglist-al...@example.org' mailing list, but
of course you know that this is just a figure of speech.
On lists that do not have subscription moderation, users can add
themselves to the "allow" database in the same way. This is
documented only briefly in the USER'S manual.
Archive access may also be restricted to subscribers. Like
subscribers of the list or the digest list, addresses in the
"allow" database are allowed to access the archive.
Therefore it seems that unsubscribing is the only action a user may
take to avoid receiving email. The above requires the mailing list
owner to take action.
Bob
Hi! This is the ezmlm program. I'm managing the
users@spamassassin.apache.org mailing list.
This is a generic help message. The message I received wasn't sent to
any of my command addresses.
--- 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
Re: Spamassassin goes to folder spam
On Tue, 20 Apr 2021 01:12:18 +0200 mau...@gmx.ch wrote: > Hello > > Asking for litle help.. Doevecot and sieve are running fine.. One > thing now, if receiving mail from Users-spamassassin > > This mail will by forwarding from sieve to folder spam. I didn't see > why this will transfer there. You have two conflicting X-Spam-flag headers. This isn't why your email wasn't filtered into the list folder, but it's the more serious problem. Ordinarily SA will strip any pre-existing X-Spam-* headers, which suggests some other software is calling SA as a library and writing its own headers. If possible configure a header with a different and unique name.
Re: How do you set nomail for the List?
On Tuesday 20 April 2021 at 22:54:29, RW wrote: > On Tue, 20 Apr 2021 10:21:57 -0600 Bob Proulx wrote: > > Don Saklad wrote: > > > How do you set nomail for the List? > > > > To unsubscribe send an email message to this address. Followed by a > > pre-mangled address for the web archive readers that hide email > > addresses. > > > > users-unsubscr...@spamassassin.apache.org > > I think the question was getting no mail without unsubscribing and > losing the ability to post. This is useful if you read a list by other > means, e.g. via NNTP. I thought the question was for someone being away for some time and not wanting to build up list emails which wouldn't be replied to, and therefore probably also wouldn't be worth reading upon the return. mailman supports this on its web interface; I can't see the equivalent function on what this list runs on. Incidentally, I had no idea what "a pre-mangled address for the web archive readers" meant. Antony. -- "Can you keep a secret?" "Well, I shouldn't really tell you this, but... no." Please reply to the list; please *don't* CC me.
Re: How do you set nomail for the List?
On Tue, 20 Apr 2021 10:21:57 -0600 Bob Proulx wrote: > Don Saklad wrote: > > How do you set nomail for the List? > > To unsubscribe send an email message to this address. Followed by a > pre-mangled address for the web archive readers that hide email > addresses. > > users-unsubscr...@spamassassin.apache.org I think the question was getting no mail without unsubscribing and losing the ability to post. This is useful if you read a list by other means, e.g. via NNTP.
Re: How do you set nomail for the List?
Don Saklad wrote: > How do you set nomail for the List? To unsubscribe send an email message to this address. Followed by a pre-mangled address for the web archive readers that hide email addresses. users-unsubscr...@spamassassin.apache.org users-unsubscribe AT spamassassin DOT apache DOT org For general information about the mailing lists: https://cwiki.apache.org/confluence/display/SPAMASSASSIN/MailingLists Bob
Re: Senderscore
On 20 Apr 2021, at 7:27, Simon Wilson wrote: > ...is the correct way to disable it: > > local.cf: score RCVD_IN_VALIDITY_RPBL 0 Yes. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: KAM_DMARC_REJECT on internal emails
On 20 Apr 2021, at 7:48, Matus UHLAR - fantomas wrote: On 19 Apr 2021, at 21:28, John Hardin wrote: ...so: header ALL_INTERNAL X-Spam-Relays-External =~ /^$/ ? On 19.04.21 22:15, Bill Cole wrote: Actually, what I committed earlier today in my sandbox and will move to the main rules tree if it doesn't do anything crazy in masschecks: describe __NO_EXTERNALS No external relays header __NO_EXTERNALS X-Spam-Relays-External =~ /^$/ describe ALL_INTERNAL Has only internal relays meta ALL_INTERNAL __NO_EXTERNALS && !NO_RELAYS tflags ALL_INTERNAL nice afik NO_RELAYS hits when mail was locally generated, which means, so you need at least one relay, otherwise it won't hit. Are you sure you need it this way? Sure? I'm rarely sure about anything... It was suggested to me off-list and I think it makes sense from a broad view to have non-overlapping full coverage of the possibilities and semantic consistency across "ALL_TRUSTED" and "ALL_INTERNAL" in asserting that "ALL" is non-zero. However, it does make sense in this case to exclude __NO_EXTERNALS from DMARC checking rather than ALL_INTERNAL. I'm undecided on whether either actually needs to be a scored rule. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: KAM_DMARC_REJECT on internal emails
header DMARC_FAIL_REJECT Authentication-Results =~ /mail\.simonandkate\.net; dmarc=fail \(p=reject/ describe DMARC_FAIL_REJECT DMARC check failed (p=reject) score DMARC_FAIL_REJECT 6.0 That works fine, this rule is DMARC testing in OUTbound mail, dont do this :) ***No it is not DMARC testing in OUTbound mail*** (not shouting, just stressing this point) Read my message again please :) I have said a few times I do *not* run milters on outbound email, so the header that rule tests for *does not exist on outbound email*, and so the custom DMARC rule does not trigger on outbound email. It DOES trigger on INbound emails, which is correct. the rule is fine for INbound mail, IF you use opendmarc before spamassassin milter, there is no garenti that spamassassin see opendmarc results in that chains of trustness its safe to remove all AR headers before doing own milters that add local testing and trusted headers, AR headers is not DKIM signed by a good reason :=) and has the bonus of only running when I expect it to - which is when I have ensured the relevant milters have run and added trusted headers on inbound email. irrelevant since the rule in spamassassin is still used in OUTbound and INbound, it will give false possitive testing this in spamassassin, work around could be to have spamd for inbound,and spamd for outbound, but this needs new rules for outbound :=) Sorry, you have not understood what I have written. I will try and be clearer: - OpenDMARC only runs on inbound email (controlled as a milter only on port 25 inbound Postfix) - When OpenDMARC runs it adds an Authentication-Results header with a trusted Authserv-ID - Only when that header exists does the rule trigger in Spamassassin, i.e. THE RULE ONLY TRIGGERS ON INBOUND -- Simon Wilson M: 0400 12 11 16
Re: KAM_DMARC_REJECT on internal emails
On 2021-04-20 14:48, Simon Wilson wrote: score__KAM_DMARC_POLICY_REJECT 0 score__KAM_DMARC_POLICY_QUAR 0 score__KAM_DMARC_POLICY_NONE 0 score__KAM_DMARC_POLICY_DKIM_STRICT0 ... as then the metas will never pass. any solutions creates another problem
Re: KAM_DMARC_REJECT on internal emails
On 2021-04-20 14:35, Henrik K wrote: > On Mon, Apr 19, 2021 at 10:05:21PM +1000, Simon Wilson wrote: rather than change the channel distributed KAM.cf, what needs to go in local.cf to tell that not to run? *CAN* it be disabled from local.cf, or can it only be done by commenting out the entry in KAM.cf? It would not make any sense to not be able to override things. Or edit a channel file which would later be overwritten? Of course you can disable it in local.cf: score __KAM_DMARC_POLICY_REJECT 0 i just say it does not solve the real problem it possible already solved in spamassassin 4 is it time for RFE with running spamd for indbound and another spamd for outbound ? Framework is still missing for this
Re: KAM_DMARC_REJECT on internal emails
> On Mon, Apr 19, 2021 at 10:05:21PM +1000, Simon Wilson wrote: rather than change the channel distributed KAM.cf, what needs to go in local.cf to tell that not to run? *CAN* it be disabled from local.cf, or can it only be done by commenting out the entry in KAM.cf? It would not make any sense to not be able to override things. Or edit a channel file which would later be overwritten? Of course you can disable it in local.cf: score __KAM_DMARC_POLICY_REJECT 0 Thanks Henrik - So KAM.cf's askdns __KAM_DMARC_POLICY_REJECT _dmarc._AUTHORDOMAIN_ TXT /^v=DMARC1;.*\bp=reject;/ is prevented from running its DNS query by setting in local.cf: score __KAM_DMARC_POLICY_REJECT 0 That is what I wanted to understand :) thanks. So the best way to disable the KAM DMARC rules is not to set score 0 on the metas, but set score 0 on the askdns rules: score__KAM_DMARC_POLICY_REJECT 0 score__KAM_DMARC_POLICY_QUAR 0 score__KAM_DMARC_POLICY_NONE 0 score__KAM_DMARC_POLICY_DKIM_STRICT0 ... as then the metas will never pass. -- Simon Wilson M: 0400 12 11 16
Re: KAM_DMARC_REJECT on internal emails
On 2021-04-20 14:21, Simon Wilson wrote: header DMARC_FAIL_REJECT Authentication-Results =~ /mail\.simonandkate\.net; dmarc=fail \(p=reject/ describe DMARC_FAIL_REJECT DMARC check failed (p=reject) score DMARC_FAIL_REJECT 6.0 That works fine, this rule is DMARC testing in OUTbound mail, dont do this :) the rule is fine for INbound mail, IF you use opendmarc before spamassassin milter, there is no garenti that spamassassin see opendmarc results in that chains of trustness its safe to remove all AR headers before doing own milters that add local testing and trusted headers, AR headers is not DKIM signed by a good reason :=) and has the bonus of only running when I expect it to - which is when I have ensured the relevant milters have run and added trusted headers on inbound email. irrelevant since the rule in spamassassin is still used in OUTbound and INbound, it will give false possitive testing this in spamassassin, work around could be to have spamd for inbound,and spamd for outbound, but this needs new rules for outbound :=) i remember KAM sayed, the possible to do anything in Framework is stable, its just rules that is still waiting for spamassassin 4.x.x when you post problems here its a hope KAM listen on it, and will possible change the problem all the best, YMMV Simon.
Re: KAM_DMARC_REJECT on internal emails
> > On Mon, Apr 19, 2021 at 10:05:21PM +1000, Simon Wilson wrote: > > rather than change the channel distributed KAM.cf, what needs to go in > local.cf to tell that not to run? *CAN* it be disabled from local.cf, or can > it only be done by commenting out the entry in KAM.cf? It would not make any sense to not be able to override things. Or edit a channel file which would later be overwritten? Of course you can disable it in local.cf: score __KAM_DMARC_POLICY_REJECT 0
Re: KAM_DMARC_REJECT on internal emails
On 2021-04-20 13:48, Matus UHLAR - fantomas wrote: On 19 Apr 2021, at 21:28, John Hardin wrote: ...so: header ALL_INTERNAL X-Spam-Relays-External =~ /^$/ ? On 19.04.21 22:15, Bill Cole wrote: Actually, what I committed earlier today in my sandbox and will move to the main rules tree if it doesn't do anything crazy in masschecks: describe __NO_EXTERNALS No external relays header __NO_EXTERNALS X-Spam-Relays-External =~ /^$/ describe ALL_INTERNAL Has only internal relays meta ALL_INTERNAL __NO_EXTERNALS && !NO_RELAYS tflags ALL_INTERNAL nice afik NO_RELAYS hits when mail was locally generated, which means, so you need at least one relay, otherwise it won't hit. Are you sure you need it this way? !NO_RELAYS is external ip since NO_RELAYS is internal_networks this is so cool that Bill created another rule for ALL_EXTERNAL when NO_RELAYS exists :/ please fokus on DKIM signed mails is LOCAL domains or not KAM cant help knowing what is local or not, we all wait for spamassassin 4.x.x where this mess is solved by no need for any rules waste anymore Bill have this in mind when AuthRes doing this on 4.x.x then KAM rule will be not needed or atleast change for 4.x.x usage hope the best for the future of spamassassin
Re: KAM_DMARC_REJECT on internal emails
They do yes. However I use fetchmail to retrieve emails from some services; fetchmail presents into the inbound stack as being from 127.0.0.1 - so I do not use the milters' "whitelists" to decide whether or not to run on inbound email, I use directed flow through postfix and amavisd to decide whether or not the milters are run. make your fetchmail use mda, problem solved In the context of my query here on *outbound* email... I do *not* run milters on outbound email, so it is only the KAM DMARC rules which were running regardless which generated an issue. fetchmail is inbound not outbound, kam rule is not a milter Hi Benny, The original issue was OUTbound all-internal email. You mentioned milters whitelisting 127.0.0.1 which as my milters only run on INbound is irrelevant to the original issue (none of my milters run on internal-->internal email). My comment on fetchmail was to point out one example of where I change milters to *not* ignore localhost: you cannot assume milters *always* ignore localhost just because they do by default. And I do not have a problem with fetchmail to solve - it works well, configured to drop to my smtphost where milters *do* process it as inbound email, even though it is seen as being from localhost (the fetchmail daemon smtphost drops it to a specific postfix instance). Anyway, back to OUTBOUND internal-->internal :) When SA runs in this scenario email has not been DKIM signed, SPF is irrelevant, and the email has never left my perimeter - a DMARC evaluation should NOT be run. It looks like there are some good ideas on how to resolve that, for which I am grateful. FWIW... Whilst I can see the value of the KAM DMARC rules for an "out of the box" install of SA, I will likely leave them disabled on ALL email: I have a robust inbound milter setup which adds sequentially trusted headers for SPF, DKIM, ARC and DMARC. My preference is for SA to use \existing trusted headers/ to base DKIM, SPF, ARC, DMARC score decisions on - *NOT* to run additional DNS lookups to do its own when they have already been done (even though likely nameserver-cached). I already do this with DMARC, which SA does not do DNS-checking tests for (out of the box, i.e. without KAM rules). I have custom rules in local.cf which use the headers provided by OpenDMARC: e.g. header DMARC_FAIL_REJECT Authentication-Results =~ /mail\.simonandkate\.net; dmarc=fail \(p=reject/ describe DMARC_FAIL_REJECT DMARC check failed (p=reject) score DMARC_FAIL_REJECT 6.0 That works fine, and has the bonus of only running when I expect it to - which is when I have ensured the relevant milters have run and added trusted headers on inbound email. Simon. -- Simon Wilson M: 0400 12 11 16
Re: KAM_DMARC_REJECT on internal emails
On 19 Apr 2021, at 21:28, John Hardin wrote: ...so: header ALL_INTERNAL X-Spam-Relays-External =~ /^$/ ? On 19.04.21 22:15, Bill Cole wrote: Actually, what I committed earlier today in my sandbox and will move to the main rules tree if it doesn't do anything crazy in masschecks: describe __NO_EXTERNALS No external relays header __NO_EXTERNALS X-Spam-Relays-External =~ /^$/ describe ALL_INTERNAL Has only internal relays meta ALL_INTERNAL __NO_EXTERNALS && !NO_RELAYS tflags ALL_INTERNAL nice afik NO_RELAYS hits when mail was locally generated, which means, so you need at least one relay, otherwise it won't hit. Are you sure you need it this way? -- 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. There's a long-standing bug relating to the x86 architecture that allows you to install Windows. -- Matthew D. Fuller
Re: KAM_DMARC_REJECT on internal emails
On 19 Apr 2021, at 11:30, Matus UHLAR - fantomas wrote: I understand this as: if mail was received by internal relay unauthenticated, it's external, On 19.04.21 12:49, Bill Cole wrote: I cannot make SA behave that way. On 19 Apr 2021, at 13:03, Matus UHLAR - fantomas wrote: why not? On 19.04.21 13:20, Bill Cole wrote: When I provide SA with a message that has stepped through 2 internal machines with no authentication, SA *DOES NOT* insert any information about the relay host in X-Spam-Relays-External. OK, this how I understand it: __LAST_EXTERNAL_RELAY_NO_AUTH - message received from external (by internal) network unauthenticated - incoming message - check SPF/DKIM/DMARC !__LAST_EXTERNAL_RELAY_NO_AUTH - message received from external (by internal) network authenticated - locally generated/outgoing message - don't check SPF/DKIM/DMARC, may DKIM-sign e.g., these received headers: Return-Path: Received: from skinnyclam.scconsult.com (skinnyclam.scconsult.com [192.168.254.125]) by toaster.scconsult.com (Postfix) with ESMTP id 4FP7Tb0wWWz5q7dl for ; Mon, 19 Apr 2021 09:49:23 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by skinnyclam.scconsult.com (Postfix) with ESMTP id D74214C88329 for ; Mon, 19 Apr 2021 09:49:22 -0400 (EDT) Results in these RELAYS* assignments: Apr 19 12:38:23.932 [14599] dbg: check: tagrun - tag RELAYSTRUSTED is now ready, value: [ ip=192.168.254.125 rdns=skinnyclam.scconsult.com helo=skinnyclam.scconsult.com by=bigsky.scconsult.com ident= envfrom=r...@skinnyclam.scconsult.com intl=1 id=4FP7Tb0wWWz5q7dl auth= msa=0 ] [ ip=127.0.0.1 rdns=localhost helo=localhost by=skinnyclam.scconsult.com ident= envfrom=r...@skinnyclam.scconsult.com intl=1 id=D74214C88329 auth= msa=0 ] Apr 19 12:38:23.932 [14599] dbg: check: tagrun - tag RELAYSUNTRUSTED is now ready, value: Apr 19 12:38:23.932 [14599] dbg: check: tagrun - tag RELAYSINTERNAL is now ready, value: [ ip=192.168.254.125 rdns=skinnyclam.scconsult.com helo=skinnyclam.scconsult.com by=bigsky.scconsult.com ident= envfrom=r...@skinnyclam.scconsult.com intl=1 id=4FP7Tb0wWWz5q7dl auth= msa=0 ] [ ip=127.0.0.1 rdns=localhost helo=localhost by=skinnyclam.scconsult.com ident= envfrom=r...@skinnyclam.scconsult.com intl=1 id=D74214C88329 auth= msa=0 ] Apr 19 12:38:23.932 [14599] dbg: check: tagrun - tag RELAYSEXTERNAL is now ready, value: this should be the correct case above - this is mail created in your network, you chould not check, but sign it instead. -- 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: Senderscore
And btw, usually on the DNS infos of Senderscores, you can see about 3
days of lag compared to their online interface, dunno if expected on
their side, or they're facing perf issues, but that service is not a
top priority at all at least
On Mon, Apr 19, 2021 at 7:29 PM Simon Bressier wrote:
Hi Simon,
For info for few days now, the Senderscore DNS server is failing to
answer. I've pinged one relation I have at Validity so they can dig on
it.
Senderscore via DNS is a legacy service they just maintain but dunno
for how long... They are more on a mood to stop that service in the
future to push to their API usage, and you ofc need to be client to
use it :)
Seems like a good candidate to be dropped from tests.
That dnsbl is called in 20_dnsbl_tests.cf as follows:
# Validity RPBL (née Return Path Reputation Network Blacklist - RNBL):
# https://www.senderscore.org/blocklistlookup/
# (replaces RCVD_IN_RP_RNBL)
header RCVD_IN_VALIDITY_RPBL
eval:check_rbl('rnbl-lastexternal','bl.score.senderscore.com.')
describe RCVD_IN_VALIDITY_RPBL Relay in Validity RPBL,
https://senderscore.org/blocklistlookup/
tflags RCVD_IN_VALIDITY_RPBL net publish
reuse RCVD_IN_VALIDITY_RPBL RCVD_IN_RP_RNBL
...is the correct way to disable it:
local.cf: score RCVD_IN_VALIDITY_RPBL 0
?
Simon
--
Simon Wilson
M: 0400 12 11 16
Re: KAM_DMARC_REJECT on internal emails
>On 19 Apr 2021, at 11:30, Matus UHLAR - fantomas wrote: >> I understand this as: >> >> if mail was received by internal relay unauthenticated, it's >> external, On 19.04.21 12:49, Bill Cole wrote: >I cannot make SA behave that way. On Mon, 19 Apr 2021 19:03:55 +0200 Matus UHLAR - fantomas wrote: why not? meta KAM_DMARC_REJECT __LAST_EXTERNAL_RELAY_NO_AUTH && !(DKIM_VALID_AU || SPF_PASS) && __KAM_DMARC_POLICY_REJECT should avoid KAM_DMARC_REJECT if the mail was accepted authenticated by internal relay from external one. On 19.04.21 18:19, RW wrote: __LAST_EXTERNAL_RELAY_NO_AUTH will hit if an email arrived in the internal network from external-trusted. that should be it, DKIM should be checked at internal network border, so it should be checked even when receiving mail from trusted (but not internal) hosts. -- 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. Fucking windows! Bring Bill Gates! (Southpark the movie)
Re: KAM_DMARC_REJECT on internal emails
- Message from Henrik K - Date: Mon, 19 Apr 2021 17:11:41 +0300 From: Henrik K Reply-To: users@spamassassin.apache.org Subject: Re: KAM_DMARC_REJECT on internal emails To: users@spamassassin.apache.org On Mon, Apr 19, 2021 at 10:05:21PM +1000, Simon Wilson wrote: askdns __KAM_DMARC_POLICY_REJECT _dmarc._AUTHORDOMAIN_ TXT /^v=DMARC1;.*\bp=reject;/ run anyway? Or only if the resultant metas which call on them have a score value <> 0? Askdns is like any other rule, it does what it's told to do with little regard to anything else. So yes you must disable it specifically, if you don't want it to do something. Well this thread kinda developed a life of its own... lol... Anyhoo... until the ALL_INTERNAL question is sorted, how do I disable an "askdns" rule from running so it is not making unnecessary DNS calls? I have for now put this in local.cf: scoreKAM_DMARC_STATUS 0.0 scoreKAM_DMARC_REJECT 0.0 scoreKAM_DMARC_QUARANTINE 0.0 scoreKAM_DMARC_NONE 0.0 so it disables the meta rules... but how to stop the askdns queries, e.g. in KAM.cf: askdns __KAM_DMARC_POLICY_REJECT _dmarc._AUTHORDOMAIN_ TXT /^v=DMARC1;.*\bp=reject;/ rather than change the channel distributed KAM.cf, what needs to go in local.cf to tell that not to run? *CAN* it be disabled from local.cf, or can it only be done by commenting out the entry in KAM.cf? Simon. -- Simon Wilson M: 0400 12 11 16
