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.
Right. And any software that can use localhos
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 localhost (or any other unqualified name
> whos
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 because it poses a real risk of duplication.
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
wrote:
> About 1.5% of my personal non-
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 guar
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
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 Cole
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
val
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
(version=TLS1_
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 domain
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 like measles. Once you've
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:1
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 "@" dom
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 all
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 (msg-id)
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 I
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
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 include the fqdn or address > literal of the
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).
Accordin
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 su
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:
No,
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
i
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 behavior
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...
>
> Inte
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
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 following
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 =
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 the construction of t
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
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 site's
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 2
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:
https://t
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.
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
m
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 but
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, Ja
> 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 lett
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 "Content-Transf
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
39 matches
Mail list logo
