Re: Malformed spam email gets through.

On 4 Jan 2018, at 21:13 (-0500), @lbutlr wrote: On 4 Jan 2018, at 11:47, Bill Cole wrote: On 3 Jan 2018, at 15:42, @lbutlr wrote: There is no requirement that the right side be globally unique, just that the entire message ID is globally unique.

Re: Malformed spam email gets through.

On 4 Jan 2018, at 11:47, Bill Cole wrote: > On 3 Jan 2018, at 15:42, @lbutlr wrote: >> There is no requirement that the right side be globally unique, just that >> the entire message ID is globally unique. > > Right. And any software that can use

Re: Malformed spam email gets through.

On 3 Jan 2018, at 15:42, @lbutlr wrote: [...] On 03 Jan 2018, at 12:36, Bill Cole wrote: About 1.5% of my personal non-spam email over the past 20 years has had "localhost" as the right hand side of the MID. This implies a de facto RFC violation

Re: Malformed spam email gets through.

On 03 Jan 2018, at 04:57, Matus UHLAR - fantomas wrote: > while it's "only" recommended that the right part is a domain name, but > there must be right part. Yes, there must be a left and a right and an ‘@‘ in-between. On 03 Jan 2018, at 12:36, Bill Cole

Re: Malformed spam email gets through.

On 2018-01-03 14:36, Bill Cole wrote: > I have run an environment where each MTA node in the external gateway > layer would add a MID with its own FQDN to any message passing through > missing a MID. Those names could not be resolved in the world at > large, but they were absolutely valid and

Re: Malformed spam email gets through.

On 2 Jan 2018, at 20:39, Alex wrote: Is it possible to at least enforce that the message-ID has a valid domain? Not reliably. About 1.5% of my personal non-spam email over the past 20 years has had "localhost" as the right hand side of the MID. This implies a de facto RFC violation because

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 12:17, Bill

Re: Malformed spam email gets through.

On Wednesday 03 January 2018 at 02:39:54, Alex wrote: > Hi, > > Is it possible to at least enforce that the message-ID has a valid domain? If by "enforce" you mean "require" (in other words, you look at whatever message-ID the incoming email has, and you decide that if it doesn't contain a

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: 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: 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.

with [ProtonMail](https://protonmail.com) Secure Email. > Original Message > Subject: Re: Malformed spam email gets through. > Local Time: 2 January 2018 9:54 AM > UTC Time: 2 January 2018 08:54 > From: r...@protonmail.com > To: users@spamassassin.apache.org > &g

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).

Re: Malformed spam email gets through.

On 1 Jan 2018, at 14:30 (-0500), Alan Hodgson wrote: On Mon, 2018-01-01 at 10:29 -0500, Bill Cole wrote: [...] HOWEVER, the idea of enforcing any standard on MIDs beyond gross format  (e.g.: <[[:ascii:]]{3,996}>) on a system where the admin isn't the sole  user is ludicrous. I've had good

Re: Malformed spam email gets through.

On 1 Jan 2018, at 12:47 (-0500), Matus UHLAR - fantomas 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 12:17, Bill Cole wrote:

Re: Malformed spam email gets through.

On 01/01/2018 01:30 PM, Alan Hodgson wrote: I've had good success junking anything with one of my domains in the message-id, where I know the mail isn't actually from someone in that domain. That's a pretty solid spam signature. are you sure it's not your mailservers adding Message-Id to the

Re: Malformed spam email gets through.

On 01/01/2018 01:30 PM, Alan Hodgson wrote: On Mon, 2018-01-01 at 10:29 -0500, Bill Cole wrote: On 1 Jan 2018, at 9:59 (-0500), David Jones wrote: I think some mail systems will keep the same message-ID per email thread so your system must reject some replies. I have not seen such

Re: Malformed spam email gets through.

On Mon, 2018-01-01 at 10:29 -0500, Bill Cole wrote: > On 1 Jan 2018, at 9:59 (-0500), David Jones wrote: > > > I think some mail systems will keep the same message-ID per email  > > thread so your system must reject some replies. > > I have not seen such behavior in the past 20 years... > >

Re: Malformed spam email gets through.

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 12:17, Bill Cole wrote: No, it does not. Re-read the cited sections. From RFC5322, the ABNF

Re: Malformed spam email gets through.

David Jones skrev den 2018-01-01 15:59: There is no way that most of us on this mailing list can be as strict or our customers would complain constantly about missing email. postfix add rfc message-id on mails that dont follow rfcs, so first mta (postfix here) hiddes mua's fault not

Re: Malformed spam email gets through.

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 "@". No, it does not. Re-read the cited sections. From RFC5322, the ABNF definition: msg-id

Re: Malformed spam email gets through.

On 1 Jan 2018, at 09:41, Matus UHLAR - fantomas wrote: > the gross format in RFCs 822,2822 and 5322 describes message-id consisting > of local and domain part, You are misreading the RFC. The Message-ID itself is a *should* and there is no MUST un any of the description of

Re: Malformed spam email gets through.

On 1 Jan 2018, at 10:33 (-0500), David Jones wrote: On 01/01/2018 09:29 AM, Bill Cole wrote: On 1 Jan 2018, at 9:59 (-0500), David Jones wrote: I think some mail systems will keep the same message-ID per email thread so your system must reject some replies. I have not seen such behavior in

Re: Malformed spam email gets through.

On 1 Jan 2018, at 9:59 (-0500), David Jones wrote: I think some mail systems will keep the same message-ID per email thread so your system must reject some replies. On 01.01.18 10:29, Bill Cole wrote: I have not seen such behavior in the past 20 years... Intentionally re-using another

Re: Malformed spam email gets through.

On 01/01/2018 09:33 AM, David Jones wrote: On 01/01/2018 09:29 AM, Bill Cole wrote: On 1 Jan 2018, at 9:59 (-0500), David Jones wrote: I think some mail systems will keep the same message-ID per email thread so your system must reject some replies. I have not seen such behavior in the past

Re: Malformed spam email gets through.

On 1 Jan 2018, at 3:54 (-0500), Rupert Gallagher wrote: We reject anything whose mid does not include the fqdn or address literal of their sending server. We do this because the RFC says explicitly that the mid *MUST* have those features. This is a blatant falsehood. Relevant RFCs:

Re: Malformed spam email gets through.

On 01/01/2018 09:29 AM, Bill Cole wrote: On 1 Jan 2018, at 9:59 (-0500), David Jones wrote: I think some mail systems will keep the same message-ID per email thread so your system must reject some replies. I have not seen such behavior in the past 20 years... Ok. I stand corrected then.

Re: Malformed spam email gets through.

On 1 Jan 2018, at 9:59 (-0500), David Jones wrote: I think some mail systems will keep the same message-ID per email thread so your system must reject some replies. I have not seen such behavior in the past 20 years... Intentionally re-using another site's MIDs is so wrong that I'd happily

Re: Malformed spam email gets through.

On 01/01/2018 02:54 AM, Rupert Gallagher wrote: We reject anything whose mid does not include the fqdn or address literal of their sending server. We do this because the RFC says explicitly that the mid *MUST* have those features. We write exceptions for those few senders who are legitimate

Re: Malformed spam email gets through.

We reject anything whose mid does not include the fqdn or address literal of their sending server. We do this because the RFC says explicitly that the mid *MUST* have those features. We write exceptions for those few senders who are legitimate but have lazy and incompetent sysadmins. On Mon,

Re: Malformed spam email gets through.

> Also, can anyone suggest a nicely written rule, that triggers when an html > tag's text contains both upper and lower case letters?  Thanks. - Mark Hi Mark and happy new year! For small tags a simple rule, uggly but very cheap, may work:  /Src|sRc|srC|.. and son on   number of

Re: Malformed spam email gets through.

On 12/31/2017 05:15 PM, Mark London wrote: Hi - I previously mentioned that I was getting emails with hand created html tags, that had both uppercase and lowercase letters. I created a crude rawbody rule to test for them. It worked, until the spammer accidentally added the line

Malformed spam email gets through.

Hi - I previously mentioned that I was getting emails with hand created html tags, that had both uppercase and lowercase letters. I created a crude rawbody rule to test for them. It worked, until the spammer accidentally added the line "Content-Transfer-Encoding: base64", even though the body