Mailing List Archive

On Thu, 2020-01-02 at 16:08 -0700, Philip Prindeville wrote:
> I’m getting the following Spam.
>
> http://www.redfish-solutions.com/misc/bluechew.eml
>
> And this is notable for having:
>
> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-
> 1"><style>
>
> GUID1
> GUID2
> GUID3
> GUID4
> …
> </style>

I've also been getting a number of these, and someone else on this list
reported the same format. I haven't seen a SA rules solution to
blocking these.

--
Lindsay Haisley | "The first casualty when
FMP Computer Services | war comes is truth."
512-259-1190 |
http://www.fmp.com | -- Hiram W Johnson

Philip Prindeville wrote:
> I’m getting the following Spam.
>
> http://www.redfish-solutions.com/misc/bluechew.eml

Received: from phylobago.mysecuritycamera.org
(ec2-34-210-5-63.us-west-2.compute.amazonaws.com [34.210.5.63])

I have a local rule adding a couple of points for anything coming
direct-to-MX from any Amazon compute node, period.

I added this on the basis of Amazon's abuse-reporting web form insisting
that activity from any given IP may be from many AWS customers over a
span of a few minutes. Legitimate mail servers do not randomly change
sending or receiving domains over this timespan, so therefore, Amazon
compute nodes should not be sending direct-to-MX, at all, ever.

Reality has intruded and there are in fact static IP assignments in the
.compute.amazonaws.com tree (as well as ISP customers of ours who have
websites with webforms on AWS, which send mail to their ISP mailbox - or
sometimes their domain mailbox that's hosted with us) - otherwise I'd
have scored the rule a lot higher.

> And this is notable for having:
>
> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"><style>
>
> GUID1
> GUID2
> GUID3
> GUID4
> …
> </style>
>
> so it should be easy enough to detect.

I've posted about other variations on the "invalid <style> tag" subject
in the past. I've settled for these rules:

full EXTRALONG_STYLE m|<style(?:
type="text/css")?>[^<]{10000,30000}<\/style>|s

This is capped at a round 30K mainly because you have to recompile Perl
to use quantifiers larger than 32767.

In practice I have historically seen <style> gibberish closing on 1MB,
and I have also unfortunately seen nominally legitimate <style> tags
pushing 50KB or so (I'm glaring at you, Outlook).

rawbody INVALID_STYLE
m|(?!<style>\s+</style>)<style>[a-z0-9\s\n/'-]+</style>|i

This should sweep up a lot of garbage that isn't valid CSS. The
specifics of what kind of garbage aren't really interesting over the
long term. It doesn't match this particular example, but if you switch
it to a full rule as well, it does. I think I was targeting (much)
shorter blobs that didn't hit EXTRALONG_STYLE in using rawbody instead
of full; it's been a while since I've looked closely at these or seen
any FNs that seemed relevant.


> The 2nd type of Spam I’m seeing looks like:
>
> http://www.redfish-solutions.com/misc/received-spf.eml
>
> which contains:
>
> Received: from mta.amapspa.it ([127.0.0.1])
> by localhost (mta.amapspa.it [127.0.0.1]) (amavisd-new, port 10026)
> with ESMTP id U5M-E2lVwWem; Sat, 2 Nov 2019 00:19:36 +0100 (CET)
> Received-SPF: none (amapspa.it: No applicable sender policy available) receiver=mta.amapspa.it; identity=mailfrom; envelope-from="dario.scarpulla@amapspa.it"; helo="[91.134.159.128]"; client-ip=91.134.159.128
> Received-SPF: none (amapspa.it: No applicable sender policy available) receiver=mta.amapspa.it; identity=mailfrom; envelope-from="dario.scarpulla@amapspa.it"; helo="[91.134.159.128]"; client-ip=91.134.159.128
> Received-SPF: none (amapspa.it: No applicable sender policy available) receiver=mta.amapspa.it; identity=mailfrom; envelope-from="dario.scarpulla@amapspa.it"; helo="[91.134.159.128]"; client-ip=91.134.159.128
> …
>
> with that line being repeated some 40 times, each line being identical.
>
> I tried a rule like:
>
> header __L_RECEIVED_SPF exists:Received-SPF
> tflags __L_RECEIVED_SPF multiple maxhits=20
>
> meta L_RECEIVED_SPF (__L_RECEIVED_SPF >= 10)
> describe L_RECEIVED_SPF Crazy numbers of Received-SFP headers
> score L_RECEIVED_SPF 20.0
>
>
> but it never seems to match. I’ve not tried to debug this, but it seems that duplicated headers might not be saved as a list into the headers? (Is there an easy way to see what exists:Received-SPF is evaluating as?)

IIRC if you want to catch something like this you have to use the ALL
metaheader and chew through the entire header section as a block.
Something like:

header __MANY_RCVD_SPF ALL:raw =~ /^Received-SPF:/m
tflags __MANY_RCVD_SPF multiple maxhits=20
meta MANY_RCVD_SPF __MANY_RCVD_SPF >= 10

exists: in particular I think is effectively boolean, by definition it
either hits once or it doesn't hit at all.

*prods rules*

This also works:

header MANY_RCVD_SPF Received-SPF =~ /.+/
tflags MANY_RCVD_SPF multiple maxhits=20

I'm not sure which is more efficient.

-kgd

Hi Philipe...
try this:

full __L_RECEIVED_SPF      /^Received-SPF: \w/mtflags __L_RECEIVED_SPF      multiple maxhits=11
meta L_RECEIVED_SPF        (__L_RECEIVED_SPF >= 10)describe L_RECEIVED_SPF        Crazy numbers of Received-SFP headersscore L_RECEIVED_SPF        4

-------------Pedro.

On Friday, January 3, 2020, 12:08:21 AM GMT+1, Philip Prindeville <philipp_subx@redfish-solutions.com> wrote:

I’m getting the following Spam.

http://www.redfish-solutions.com/misc/bluechew.eml

And this is notable for having:

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"><style>

GUID1
GUID2
GUID3
GUID4
…
</style>

so it should be easy enough to detect.

A GUID looks like:

[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{3}-[0-9a-f]{3}-[0-9a-f]{12}

The 2nd type of Spam I’m seeing looks like:

http://www.redfish-solutions.com/misc/received-spf.eml

which contains:

Received: from mta.amapspa.it ([127.0.0.1])
    by localhost (mta.amapspa.it [127.0.0.1]) (amavisd-new, port 10026)
    with ESMTP id U5M-E2lVwWem; Sat,  2 Nov 2019 00:19:36 +0100 (CET)
Received-SPF: none (amapspa.it: No applicable sender policy available) receiver=mta.amapspa.it; identity=mailfrom; envelope-from="dario.scarpulla@amapspa.it"; helo="[91.134.159.128]"; client-ip=91.134.159.128
Received-SPF: none (amapspa.it: No applicable sender policy available) receiver=mta.amapspa.it; identity=mailfrom; envelope-from="dario.scarpulla@amapspa.it"; helo="[91.134.159.128]"; client-ip=91.134.159.128
Received-SPF: none (amapspa.it: No applicable sender policy available) receiver=mta.amapspa.it; identity=mailfrom; envelope-from="dario.scarpulla@amapspa.it"; helo="[91.134.159.128]"; client-ip=91.134.159.128
…

with that line being repeated some 40 times, each line being identical.

I tried a rule like:

header __L_RECEIVED_SPF        exists:Received-SPF
tflags __L_RECEIVED_SPF        multiple maxhits=20

meta L_RECEIVED_SPF            (__L_RECEIVED_SPF >= 10)
describe L_RECEIVED_SPF        Crazy numbers of Received-SFP headers
score L_RECEIVED_SPF            20.0


but it never seems to match.  I’ve not tried to debug this, but it seems that duplicated headers might not be saved as a list into the headers?  (Is there an easy way to see what exists:Received-SPF is evaluating as?)

If that’s the case, it would seem to be a shortcoming.

Can anyone confirm that’s indeed what’s happening?

Thanks,

-Philip

On Fri, 3 Jan 2020, Pedro David Marco wrote:

> header __L_RECEIVED_SPF        exists:Received-SPF
> tflags __L_RECEIVED_SPF        multiple maxhits=20
>
> meta L_RECEIVED_SPF            (__L_RECEIVED_SPF >= 10)
> describe L_RECEIVED_SPF        Crazy numbers of Received-SFP headers
> score L_RECEIVED_SPF            20.0
>
> but it never seems to match.

"exists" is a boolean, it's reasonable that it only returns one hit
regardless of the number of instances present.

Try this instead, to actually match the header(s):

header __L_RECEIVED_SPF       Received-SPF =~ /^./

--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
USMC Rules of Gunfighting #20: The faster you finish the fight,
the less shot you will get.
-----------------------------------------------------------------------
306 days until the Presidential Election

On Fri, 3 Jan 2020 10:09:21 -0800 (PST)
John Hardin wrote:

> On Fri, 3 Jan 2020, Pedro David Marco wrote:
>
> > header __L_RECEIVED_SPF        exists:Received-SPF
> > tflags __L_RECEIVED_SPF        multiple maxhits=20
> >
> > meta L_RECEIVED_SPF            (__L_RECEIVED_SPF >= 10)
> > describe L_RECEIVED_SPF        Crazy numbers of Received-SFP headers
> > score L_RECEIVED_SPF            20.0
> >
> > but it never seems to match.
>
> "exists" is a boolean, it's reasonable that it only returns one hit
> regardless of the number of instances present.
>
> Try this instead, to actually match the header(s):
>
> header __L_RECEIVED_SPF       Received-SPF =~ /^./

That should be:

header __L_RECEIVED_SPF       Received-SPF =~ /^./m

> On Jan 3, 2020, at 11:34 AM, RW <rwmaillists@googlemail.com> wrote:
>
> On Fri, 3 Jan 2020 10:09:21 -0800 (PST)
> John Hardin wrote:
>
>> On Fri, 3 Jan 2020, Pedro David Marco wrote:
>>
>>> header __L_RECEIVED_SPF exists:Received-SPF
>>> tflags __L_RECEIVED_SPF multiple maxhits=20
>>>
>>> meta L_RECEIVED_SPF (__L_RECEIVED_SPF >= 10)
>>> describe L_RECEIVED_SPF Crazy numbers of Received-SFP headers
>>> score L_RECEIVED_SPF 20.0
>>>
>>> but it never seems to match.
>>
>> "exists" is a boolean, it's reasonable that it only returns one hit
>> regardless of the number of instances present.
>>
>> Try this instead, to actually match the header(s):
>>
>> header __L_RECEIVED_SPF Received-SPF =~ /^./
>
> That should be:
>
> header __L_RECEIVED_SPF Received-SPF =~ /^./m


Seems to work either way!

Thanks, everyone.

-Philip

> On Jan 2, 2020, at 4:08 PM, Philip Prindeville <philipp_subx@redfish-solutions.com> wrote:
>
> I’m getting the following Spam.
>
> http://www.redfish-solutions.com/misc/bluechew.eml
>
> And this is notable for having:
>
> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"><style>
>
> GUID1
> GUID2
> GUID3
> GUID4
> …
> </style>

One other question that occurs to me: why would we even need <meta http-equiv=“Content-Type” …> if we already have a Content-Type: header?

Isn’t that the sign of a broken MUA doing the composition? Is that on its own Spamsign (with all respect to Frank Herbert)?

-Philip

> On Jan 3, 2020, at 3:45 PM, Philip Prindeville <philipp_subx@redfish-solutions.com> wrote:
>
>
>
>> On Jan 2, 2020, at 4:08 PM, Philip Prindeville <philipp_subx@redfish-solutions.com> wrote:
>>
>> I’m getting the following Spam.
>>
>> http://www.redfish-solutions.com/misc/bluechew.eml
>>
>> And this is notable for having:
>>
>> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"><style>
>>
>> GUID1
>> GUID2
>> GUID3
>> GUID4
>> …
>> </style>
>
> One other question that occurs to me: why would we even need <meta http-equiv=“Content-Type” …> if we already have a Content-Type: header?
>
> Isn’t that the sign of a broken MUA doing the composition? Is that on its own Spamsign (with all respect to Frank Herbert)?
>
> -Philip
>


With that in mind, I’m trying out:

rawbody __L_UNNEEDED_META_CT /^<meta http-equiv="Content-Type" /m

meta T_BLOCK_MISC47 __L_UNNEEDED_META_CT
describe T_BLOCK_MISC47 Why do this when a Content-Type: header works?
score T_BLOCK_MISC47 20.0

And that seems to work.

I tried:

rawbody __L_STYLE_W_GUIDS m/<style>\n\n([0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{3}-[0-9a-f]{3}-[0-9a-f]{12}\n){10,1000}<\/style>\n/s

and couldn’t get that to match… not sure why. A way to enable dumping what’s matched the pattern buf would be handy.

But this does match:

rawbody __L_STYLE_W_GUIDS m/<style>\n\n([0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{3}-[0-9a-f]{3}-[0-9a-f]{12}\n){10,1000}/s

so it’s hard to say how much of the message it’s matching up or why. Not sure if the 2-4KB chunking is coming into play, since this is clearly longer than that.

Any suggestions for debugging a rule to see what’s matching and what’s failing to (and maybe why)?

-Philip

On Fri, 3 Jan 2020 15:29:40 -0700
Philip Prindeville wrote:

> > On Jan 3, 2020, at 11:34 AM, RW <rwmaillists@googlemail.com> wrote:
> >
> > On Fri, 3 Jan 2020 10:09:21 -0800 (PST)
> > John Hardin wrote:

> >> Try this instead, to actually match the header(s):
> >>
> >> header __L_RECEIVED_SPF Received-SPF =~ /^./
> >
> > That should be:
> >
> > header __L_RECEIVED_SPF Received-SPF =~ /^./m
>
>
> Seems to work either way!

Either should match, but without the /m it should only match once.

I just tried it and

meta L_RECEIVED_SPF (__L_RECEIVED_SPF >= 10)

doesn't work without the /m in __L_RECEIVED_SPF

On Fri, 3 Jan 2020 16:21:21 -0700
Philip Prindeville wrote:

> rawbody __L_UNNEEDED_META_CT /^<meta http-equiv="Content-Type"
> /m
>
> meta T_BLOCK_MISC47 __L_UNNEEDED_META_CT
> describe T_BLOCK_MISC47 Why do this when a
> Content-Type: header works? score T_BLOCK_MISC47 20.0
>
> And that seems to work.

I found that 9.5% of my ham matches that regex.

On Fri, 3 Jan 2020, Philip Prindeville wrote:

>
>
>> On Jan 3, 2020, at 11:34 AM, RW <rwmaillists@googlemail.com> wrote:
>>
>> On Fri, 3 Jan 2020 10:09:21 -0800 (PST)
>> John Hardin wrote:
>>
>>> On Fri, 3 Jan 2020, Pedro David Marco wrote:
>>>
>>>> header __L_RECEIVED_SPF exists:Received-SPF
>>>> tflags __L_RECEIVED_SPF multiple maxhits=20
>>>>
>>>> meta L_RECEIVED_SPF (__L_RECEIVED_SPF >= 10)
>>>> describe L_RECEIVED_SPF Crazy numbers of Received-SFP headers
>>>> score L_RECEIVED_SPF 20.0
>>>>
>>>> but it never seems to match.
>>>
>>> "exists" is a boolean, it's reasonable that it only returns one hit
>>> regardless of the number of instances present.
>>>
>>> Try this instead, to actually match the header(s):
>>>
>>> header __L_RECEIVED_SPF Received-SPF =~ /^./
>>
>> That should be:
>>
>> header __L_RECEIVED_SPF Received-SPF =~ /^./m
>
>
> Seems to work either way!

The /m shouldn't be needed given the "tflags multiple". It would be needed
if you were doing it in a plain "headers ALL =~ /.../" rule that wanted to
look at multiple headers without "tflags multiple" (which is a valid
different way to do it, but the "tflags multiple" approach is easier).

--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Anyone who uses the word "profit" as a dirty word should be
watched very, very carefully. If they hate the idea of gain
through free trade it can only mean that they?re looking to
get it through robbery. -- Lyle@Ultimak
-----------------------------------------------------------------------
305 days until the Presidential Election

On 3 Jan 2020, at 17:45, Philip Prindeville wrote:
[...]

> One other question that occurs to me: why would we even need <meta
> http-equiv=“Content-Type” …> if we already have a Content-Type:
> header?

There should be no need.

With that said, it could be *helpful* if a MUA were to save out the
text/html part as a standalone file without including any definitive
indication of the file being HTML.

> Isn’t that the sign of a broken MUA doing the composition?

Not broken (except for the fact of generating HTML for email at all, a
disease analogous to HSV-1.) It is valid HTML and can be useful in rare
circumstances.

> Is that on its own Spamsign (with all respect to Frank Herbert)?

Do you consider all mail from Facebook to be spam?

--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not For Hire (currently)

On Fri, 3 Jan 2020, RW wrote:

> On Fri, 3 Jan 2020 15:29:40 -0700
> Philip Prindeville wrote:
>
>>> On Jan 3, 2020, at 11:34 AM, RW <rwmaillists@googlemail.com> wrote:
>>>
>>> On Fri, 3 Jan 2020 10:09:21 -0800 (PST)
>>> John Hardin wrote:
>
>>>> Try this instead, to actually match the header(s):
>>>>
>>>> header __L_RECEIVED_SPF Received-SPF =~ /^./
>>>
>>> That should be:
>>>
>>> header __L_RECEIVED_SPF Received-SPF =~ /^./m
>>
>>
>> Seems to work either way!
>
> Either should match, but without the /m it should only match once.
>
> I just tried it and
>
> meta L_RECEIVED_SPF (__L_RECEIVED_SPF >= 10)
>
> doesn't work without the /m in __L_RECEIVED_SPF

Odd. I'll have to check that out. Perhaps SA is collapsing multiple
headers into a single line internally.

--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Anyone who uses the word "profit" as a dirty word should be
watched very, very carefully. If they hate the idea of gain
through free trade it can only mean that they?re looking to
get it through robbery. -- Lyle@Ultimak
-----------------------------------------------------------------------
305 days until the Presidential Election

On Sat, 4 Jan 2020, John Hardin wrote:

> On Fri, 3 Jan 2020, RW wrote:
>
>> On Fri, 3 Jan 2020 15:29:40 -0700
>> Philip Prindeville wrote:
>>
>>>> On Jan 3, 2020, at 11:34 AM, RW <rwmaillists@googlemail.com> wrote:
>>>>
>>>> On Fri, 3 Jan 2020 10:09:21 -0800 (PST)
>>>> John Hardin wrote:
>>
>>>>> Try this instead, to actually match the header(s):
>>>>>
>>>>> header __L_RECEIVED_SPF Received-SPF =~ /^./
>>>>
>>>> That should be:
>>>>
>>>> header __L_RECEIVED_SPF Received-SPF =~ /^./m
>>>
>>>
>>> Seems to work either way!
>>
>> Either should match, but without the /m it should only match once.
>>
>> I just tried it and
>>
>> meta L_RECEIVED_SPF (__L_RECEIVED_SPF >= 10)
>>
>> doesn't work without the /m in __L_RECEIVED_SPF
>
> Odd. I'll have to check that out. Perhaps SA is collapsing multiple headers
> into a single line internally.

No, the /m shouldn't be needed. There's a rule counting Apparently-To
headers in my sandbox, without the /m, and the meta with the threshold
does fire.

--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
The most glaring example of the cognitive dissonance on the left
is the concept that human beings are inherently good, yet at the
same time cannot be trusted with any kind of weapon, unless the
magic fairy dust of government authority gets sprinkled upon them.
-- Moshe Ben-David
-----------------------------------------------------------------------
305 days until the Presidential Election

On Sat, 4 Jan 2020 11:06:41 -0800 (PST)
John Hardin wrote:


> >>> Seems to work either way!
> >>
> >> Either should match, but without the /m it should only match once.
> >>
> >> I just tried it and
> >>
> >> meta L_RECEIVED_SPF (__L_RECEIVED_SPF >= 10)
> >>
> >> doesn't work without the /m in __L_RECEIVED_SPF
> >
> > Odd. I'll have to check that out. Perhaps SA is collapsing multiple
> > headers into a single line internally.

It a single string rather than a single line, but that is how header
rules work.

> No, the /m shouldn't be needed.

As I said, I tested it (just in case "tflags multiple" changed
anything). It worked as I expected, the debug shows many hits with /m
and only one without it.

> There's a rule counting Apparently-To
> headers in my sandbox, without the /m, and the meta with the
> threshold does fire.

I presume you mean:

header __APPARENTLY_TO Apparently-To =~ /<.*>/

This isn't anchored, so /m is not relevant.

On 3 Jan 2020, at 8:02, Kris Deugau wrote:

> I have a local rule adding a couple of points for anything coming
> direct-to-MX from any Amazon compute node, period.
> ?
> Reality has intruded and there are in fact static IP assignments in
> the .compute.amazonaws.com tree (as well as ISP customers of ours who
> have websites with webforms on AWS, which send mail to their ISP
> mailbox - or sometimes their domain mailbox that's hosted with us) -
> otherwise I'd have scored the rule a lot higher.

AWS offers the option to customize the PTR for elastic IPs. I very
rarely see spam coming in from AWS ranges, having non-default PTRs. I
use this to dial back my scoring a bit.

Best regards

-lem

On 1/3/2020 11:02 AM, Kris Deugau wrote:
> Philip Prindeville wrote:
>> I’m getting the following Spam.
>>
>> http://www.redfish-solutions.com/misc/bluechew.eml
>
> Received: from phylobago.mysecuritycamera.org
> (ec2-34-210-5-63.us-west-2.compute.amazonaws.com [34.210.5.63])
>
> I have a local rule adding a couple of points for anything coming
> direct-to-MX from any Amazon compute node, period.
>
> I added this on the basis of Amazon's abuse-reporting web form insisting
> that activity from any given IP may be from many AWS customers over a
> span of a few minutes.  Legitimate mail servers do not randomly change
> sending or receiving domains over this timespan, so therefore, Amazon
> compute nodes should not be sending direct-to-MX, at all, ever.
>
> Reality has intruded and there are in fact static IP assignments in the
> .compute.amazonaws.com tree (as well as ISP customers of ours who have
> websites with webforms on AWS, which send mail to their ISP mailbox - or
> sometimes their domain mailbox that's hosted with us) - otherwise I'd
> have scored the rule a lot higher.

Expect to see a lot more of these due to
https://github.com/0x4447/0x4447_product_s3_email/blob/master/README.md



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Lyle Evans wrote:
> Expect to see a lot more of these due to
> https://github.com/0x4447/0x4447_product_s3_email/blob/master/README.md

That looks more like Doing It Right(TM), by way of using Amazon's
outbound relay hosts.

Doing It Wrong(TM) is sending direct-to-MX from your VPS without
overriding the default .compute.amazon.com rDNS.

-kgd

> On Jan 4, 2020, at 11:57 AM, Bill Cole <sausers-20150205@billmail.scconsult.com> wrote:
>
> On 3 Jan 2020, at 17:45, Philip Prindeville wrote:
> [...]
>
>> One other question that occurs to me: why would we even need <meta http-equiv=“Content-Type” …> if we already have a Content-Type: header?
>
> There should be no need.
>
> With that said, it could be *helpful* if a MUA were to save out the text/html part as a standalone file without including any definitive indication of the file being HTML.


Well, it turns out that a lot of MUA’s (including Apple’s Mail.app) generates this.


>
>> Isn’t that the sign of a broken MUA doing the composition?
>
> Not broken (except for the fact of generating HTML for email at all, a disease analogous to HSV-1.) It is valid HTML and can be useful in rare circumstances.
>
>> Is that on its own Spamsign (with all respect to Frank Herbert)?
>
> Do you consider all mail from Facebook to be spam?


Is that a trick question?

-Philip