Re: Malformed spam email gets through.

Hi, Is it possible to at least enforce that the message-ID has a valid domain? Received: from thomas-krueger.local (221.208.196.104.bc.googleusercontent.com. [104.196.208.221]) by smtp-relay.gmail.com with ESMTPS id r16sm1186220uai.7.2017.12.28.18.04.13 for

Re: Malformed spam email gets through.

On 2 Jan 2018, at 04:26, Rupert Gallagher r...@protonmail.com> wrote: > Note taken. We still abide to the duties and recommendations, and expect > well-behaved servers do the same, by identifying themselves. We cross-check, > and if they lie, we block them. rejecting because they spoof a

Re: Question about BAYES_999

On 2 Jan 2018, at 07:17, David Jones djo...@ena.com> wrote: > I haven't redefined these rules from what I can tell by searching my local > rules. I would think that if I had done this, then there would be consistent > non-hits of BAYES_99 with BAYES_999 all of the time. This is only happening

Re: Malformed spam email gets through.

On 2 Jan 2018, at 03:12, Rupert Gallagher wrote: > RFC 822, pg. 30, section 6.2.3 Which is "Obsoleted by: 2822" which is "Obsoleted by: 5322" So, please find the description in RFC 5322. Helpfully, I've posted it twice in this thread. -- You know, Calculus is sort of

Re: Malformed spam email gets through.

On 1 Jan 2018, at 10:47, Matus UHLAR - fantomas uh...@fantomas.sk> wrote: > >> On 1 Jan 2018, at 11:41 (-0500), Matus UHLAR - fantomas wrote: >>> the gross format in RFCs 822,2822 and 5322 describes message-id consisting >>> of local and domain part, thus is must contain "@". > > On 01.01.18

Re: Malformed spam email gets through.

On 2 Jan 2018, at 5:12 (-0500), Rupert Gallagher wrote: This is the normative reference. This is the OBSOLETED normative reference. RFC 822, pg. 30, section 6.2.3 -- msg-id = "<" addr-spec ">"; addr-spec = local-part "@"

Re: Question about BAYES_999

On 01/02/2018 07:57 AM, RW wrote: On Mon, 1 Jan 2018 18:52:45 -0600 David Jones wrote: On 01/01/2018 06:47 PM, Reindl Harald wrote: Am 02.01.2018 um 01:18 schrieb David Jones: I just had a spam message hit BAYES_999 but not BAYES_99.  Based on BAYES_999 default score of 0.2, I thought that

Re: Question about BAYES_999

On Mon, 1 Jan 2018 18:52:45 -0600 David Jones wrote: > On 01/01/2018 06:47 PM, Reindl Harald wrote: > > > > > > Am 02.01.2018 um 01:18 schrieb David Jones: > >> I just had a spam message hit BAYES_999 but not BAYES_99.  Based > >> on BAYES_999 default score of 0.2, I thought that it was

Re: Malformed spam email gets through.

Note taken. We still abide to the duties and recommendations, and expect well-behaved servers do the same, by identifying themselves. We cross-check, and if they lie, we block them. Spammers and criminals play hide and seek, and we have both legal and contract obbligations to reject them by

Re: Malformed spam email gets through.

On Tuesday 02 January 2018 at 11:12:57, Rupert Gallagher wrote: > This is the normative reference. I've picked out the significant parts from your email... > RFC 5322, pg. 27, section 3.6.4 > --- > > << The message identifier

Re: Malformed spam email gets through.

I said "sending server", not "domain of the sender". If an e-mail from y...@rhsoft.net is sent by 95.129.202.170, your mid is expected to include either @blah. sunshine.at or @[95.129.202.170]. If the same mid includes @yahoo.com, for example, then the message is rejected as spam, because the

Re: Malformed spam email gets through.

This is the normative reference. RFC 822, pg. 30, section 6.2.3 -- msg-id = "<" addr-spec ">"; addr-spec = local-part "@" domain; domain = sub-domain *("." sub-domain); sub-domain = domain-ref / domain-literal; <> Note that the

Re: Malformed spam email gets through.

You are wrong. I will quote from the standard when I get back to my desk. Sent from ProtonMail Mobile On Mon, Jan 1, 2018 at 17:17, Bill Cole wrote: > On 1 Jan 2018, at 3:54 (-0500), Rupert Gallagher wrote: > We reject anything > whose mid does not

Re: Malformed spam email gets through.

We serve clients who must conform to certain legal and industrial standards. The general principle is to reject anything that cannot be traced back to their sender or falls outside their legal range (mail from nation X without bilateral agreement of cooperation against internet crime).