It seems some of my gmail emails just don't get through. There is no
bounce, they just vanish into a black hole.
It seems some of my gmail emails just don't get
through. There is no bounce, they just vanish into a
black hole. Similarly some emails I do not receive,
and I do not know why.
It looks like there is a history of problems between
gmail and other providers. This is because gmail is
seen by some providers as a source of spam. There has
been friction between gmail and outlook for example.
Are we moving to a system of trust with email, where--
the default position is no trust? Will people drift to
Whatsapp because there is no way to troubleshoot
email? no error messages, no feedback, no support.
And I'm assuming Outlook doesn't also make messages vanish, without
showing up in the Quarantine...
Richmond wrote:
It seems some of my gmail emails just don't get through. There is no
bounce, they just vanish into a black hole.
Do you use your own domain? If so, have you got SFP and/or DKIM
configured? If not, the big providers do tend to just throw away
emails ...
Richmond wrote:
It seems some of my gmail emails just don't get through. There is no
bounce, they just vanish into a black hole.
Do you use your own domain? If so, have you got SFP and/or DKIM
configured? If not, the big providers do tend to just throw away
emails ...
No I am just using gmail as it is. Why do they throw away emails? Why
can't they tell someone what they are doing?
Do you use your own domain? If so, have you got [SPF] and/or DKIM
configured? If not, the big providers do tend to just throw away
emails ...
On Fri, 25 Sep 2026 13:53:28 +0100, Andy Burns wrote:
Do you use your own domain? If so, have you got [SPF] and/or DKIM
configured? If not, the big providers do tend to just throw away
emails ...
An SME client of mine has SPF configured on their domain. Every now
and then, they have the need to communicate with a rather large, and seemingly rather stupid Australasian corporation. These latter people
get their mail through outlook.com. But if you look at the MX record
for their domain, it points at mimecast.com.
So mail we send to them goes to mimecast.com, which does something unspeakable to it that I know nothing about, and have no wish to know.
From there it gets passed to outlook.com.
Then outlook.com does its own checks, and discovers from the SPF
record that mail from my client’s domain is only allowed to come from certain servers, which do *not* include mimecast.com. And so it
rejects the mail.
Are we supposed to add mimecast.com, an outfit we have no dealings
with and know nothing about, to our SPF record just to satisfy
somebody’s configuration screwup that isn’t even our fault? Of course not.
I’m assuming that outlook.com, being presumably run by Microsoft,
offers some way for its customers to fix its configuration to handle precisely this situation. But this particular customer of theirs seems
unable to figure this out.
It seems some of my gmail emails just don't get through. There is no
bounce, they just vanish into a black hole. Similarly some emails I do
not receive, and I do not know why.
It looks like there is a history of problems between gmail and other providers. This is because gmail is seen by some providers as a source
of spam. There has been friction between gmail and outlook for example.
Are we moving to a system of trust with email, where the default
position is no trust? Will people drift to Whatsapp because there is no
way to troubleshoot email? no error messages, no feedback, no support.
Remember when you don't pay for a product you are the product. I
would suggest maybe you should look for another email provider.
It looks like there is a history of problems between gmail and other providers. This is because gmail is seen by some providers as a source
of spam.
On Fri, 25 Sep 2026 13:39:44 +0100, Richmond wrote:
It looks like there is a history of problems between gmail and other
providers. This is because gmail is seen by some providers as a source
of spam.
You’d think Google would take better care of their own service, given
the number of suitably-qualified people they must have on their
payroll.
A few months back I was seeing a kind of spam that seemed to involve--
the setting up of mailing lists on Google Groups and subscribing
people to those lists without their permission. When a spam message
was sent out, that triggered a bunch of autoreplies from various
addresses on the list, back to the list, which were in turn sent out
to everybody. (No, luckily there was not a continuing cascade.) A real nuisance, until I added a simple header_checks entry to my Postfix
config which blocked them all:
/^List-Unsubscribe\:\s*.*\@googlegroups\.com/ REJECT
On Fri, 25 Sep 2026 13:39:44 +0100, Richmond wrote:
It looks like there is a history of problems between gmail and other
providers. This is because gmail is seen by some providers as a source
of spam.
You’d think Google would take better care of their own service, given
the number of suitably-qualified people they must have on their
payroll.
A few months back I was seeing a kind of spam that seemed to involve
the setting up of mailing lists on Google Groups and subscribing
people to those lists without their permission. When a spam message
was sent out, that triggered a bunch of autoreplies from various
addresses on the list, back to the list, which were in turn sent out
to everybody. (No, luckily there was not a continuing cascade.) A real >nuisance, until I added a simple header_checks entry to my Postfix
config which blocked them all:
/^List-Unsubscribe\:\s*.*\@googlegroups\.com/ REJECT
I think part of the issue is that you are using gmail. I am not sure
I would trust gmail, as if they don't like who is sending email to you
they can just not deliver it, or they can not send your email to them. Remember when you don't pay for a product you are the product. I
would suggest maybe you should look for another email provider. That
what I do, I pay for my email hosting where I have 3 email address
(across 3 domains)
Nuno Silva wrote:
And I'm assuming Outlook doesn't also make messages vanish, without
showing up in the Quarantine...
Actually, outlook does have a concept of "clutter" where it can learn
what types of email you pay no attention to, and separate them into a
clutter folder where you may not be aware they are ...
Andy Burns wrote:
outlook does have a concept of "clutter" where it can learn
what types of email you pay no attention to, and separate them into a
clutter folder where you may not be aware they are ...
I think I've heard of that one too;
This is in the new OWA webmail interface, right?
Or is this separation also exposed on e.g. IMAP?
In article <[email protected]>, Richmond <[email protected]> wrote:
If there were an email client that ignored everything except plain text, >>would it catch on? would it take the power back from whattfapp?
You mean like Heirloom mailx?
Probably not. I use Heirloom mailx myself and I love it, but sadly I am in the minority and have to deal with many people who are likely to forever remain outlook-obsessed top-mailers.
--scott
I created a search folder in Seamonkey which searches for content type >plain/text and I was surprised at how many there are, I was expecting >virtually none.
If there were an email client that ignored everything except plain text, would it catch on? would it take the power back from whattfapp?For the general public? No.
Delta Chat looked like it might, but didn't catch on.
A plain-text client could make reading cleaner, but it does not fix
the failure you describe: the sender still cannot tell whether a
message arrived or was silently filtered.
On Thu, 15 Oct 2026 14:04:14 -0000 (UTC), Martin Davies-Roundhill wrote:
A plain-text client could make reading cleaner, but it does not fix
the failure you describe: the sender still cannot tell whether a
message arrived or was silently filtered.
That’s none of the sender’s business.
On Thu, 15 Oct 2026 14:04:14 -0000 (UTC), Martin Davies-Roundhill wrote:
A plain-text client could make reading cleaner, but it does not fix
the failure you describe: the sender still cannot tell whether a
message arrived or was silently filtered.
That’s none of the sender’s business.
In article <[email protected]>, Richmond <[email protected]> wrote:
I created a search folder in Seamonkey which searches for content type >>plain/text and I was surprised at how many there are, I was expecting >>virtually none.
If people are sending plain text they probably aren't mime-encoding their messages at all so you won't see content type headers.
--scott
On 2026-10-15, Scott Dorsey wrote:
In article <[email protected]>, Richmond <[email protected]> wrote: >>>
I created a search folder in Seamonkey which searches for content
type plain/text and I was surprised at how many there are, I was >>>expecting virtually none.
If people are sending plain text they probably aren't mime-encoding
their messages at all so you won't see content type headers. --scott
I find that doubtful.
I've just checked one of my outgoing mutt messages. It has
Content-Type. Gnus, the same. Both cases text/plain.
(In fact, how do you specify the encoding without Content-Type?)
On 2026-10-15, Scott Dorsey wrote:
In article <[email protected]>, Richmond <[email protected]> wrote: >>>
I created a search folder in Seamonkey which searches for content type >>>plain/text and I was surprised at how many there are, I was expecting >>>virtually none.
If people are sending plain text they probably aren't mime-encoding their
messages at all so you won't see content type headers.
--scott
I find that doubtful.
I've just checked one of my outgoing mutt messages. It has
Content-Type. Gnus, the same. Both cases text/plain.
(In fact, how do you specify the encoding without Content-Type?)
Nuno Silva <[email protected]d> wrote:
On 2026-10-15, Scott Dorsey wrote:
In article <[email protected]>, Richmond <[email protected]> wrote:
I created a search folder in Seamonkey which searches for content type >>>> plain/text and I was surprised at how many there are, I was expecting
virtually none.
If people are sending plain text they probably aren't mime-encoding their >>> messages at all so you won't see content type headers.
--scott
I find that doubtful.
I've just checked one of my outgoing mutt messages. It has
Content-Type. Gnus, the same. Both cases text/plain.
(In fact, how do you specify the encoding without Content-Type?)
The sad fact that has been overlooked so far is that 99.9+ of those who
are still using email have no idea what a Content-Type header is, nor
do they have any idea what format they are sending, nor any idea that
they could choose to send different formats.
They use gmail (which takes care of all that technical stuff for them)
or one of the few remaining gmail competitors (hotmail/yahoo mail/etc.)
or they use their work PC which likely comes with MS Outlook and that
is what they use.
But they just "write" an email and hit "send". They don't know whether
the result is an html email, plain text email, or anything else about
the technical side. To them, it's all just a big bunch of "magic".
And as all the big "providers" seem to have decided that it is more
important that clueless users be able to bold-face, and italicize, and
change the font size, and color, and so forth, they all default to
creating and sending html format emails. The *should* include a
plain-text alternative in the final MIME package that becomes the
email, but sadly, a large number of the providers either don't create a plain-text alternative, or if they do it is one line saying "your
client can't display this email".
Nuno Silva <[email protected]d> writes:
On 2026-10-15, Scott Dorsey wrote:
In article <[email protected]>, Richmond <[email protected]>
wrote:
I created a search folder in Seamonkey which searches for content type >>>>plain/text and I was surprised at how many there are, I was expecting >>>>virtually none.
If people are sending plain text they probably aren't mime-encoding
their messages at all so you won't see content type headers. --scott
I find that doubtful.
I've just checked one of my outgoing mutt messages. It has
Content-Type. Gnus, the same. Both cases text/plain.
(In fact, how do you specify the encoding without Content-Type?)
Seamonkey cannot select for no content-type header, so I asked Claude
(yeah yeah) to write a python script to look for messages without a content-type header. It found some, not many. They tend to be automated,
e.g. Libera.chat registration, and many from a mailing list.
I've just checked one of my outgoing mutt messages. It has
Content-Type. Gnus, the same. Both cases text/plain.
(In fact, how do you specify the encoding without Content-Type?)
The sad fact that has been overlooked so far is that 99.9+ of those who
are still using email have no idea what a Content-Type header is, nor
do they have any idea what format they are sending, nor any idea that
they could choose to send different formats.
They use gmail (which takes care of all that technical stuff for them)
or one of the few remaining gmail competitors (hotmail/yahoo mail/etc.)
or they use their work PC which likely comes with MS Outlook and that
is what they use.
But they just "write" an email and hit "send". They don't know whether
the result is an html email, plain text email, or anything else about
the technical side. To them, it's all just a big bunch of "magic".
And as all the big "providers" seem to have decided that it is more important that clueless users be able to bold-face, and italicize, and change the font size, and color, and so forth, they all default to--
creating and sending html format emails. The *should* include a
plain-text alternative in the final MIME package that becomes the
email, but sadly, a large number of the providers either don't create a plain-text alternative, or if they do it is one line saying "your
client can't display this email".
Nuno Silva <[email protected]d> wrote:
I've just checked one of my outgoing mutt messages. It has
Content-Type. Gnus, the same. Both cases text/plain.
(In fact, how do you specify the encoding without Content-Type?)
You don't specify the encoding at all, you just leave it out. That's
what mailx does.
If the MTA wants to add that to the header it's welcome to do so, though. --scott--
Nuno Silva <[email protected]d> wrote:
On 2026-10-15, Scott Dorsey wrote:
In article <[email protected]>, Richmond <[email protected]> wrote:
I created a search folder in Seamonkey which searches for content
type plain/text and I was surprised at how many there are, I was >>>>expecting virtually none.
If people are sending plain text they probably aren't mime-encoding
their messages at all so you won't see content type headers.
--scott
I find that doubtful.
I've just checked one of my outgoing mutt messages. It has
Content-Type. Gnus, the same. Both cases text/plain.
(In fact, how do you specify the encoding without Content-Type?)
The sad fact that has been overlooked so far is that 99.9+ of those
who are still using email have no idea what a Content-Type header is,
nor do they have any idea what format they are sending, nor any idea
that they could choose to send different formats.
They use gmail (which takes care of all that technical stuff for them)
or one of the few remaining gmail competitors (hotmail/yahoo
mail/etc.) or they use their work PC which likely comes with MS
Outlook and that is what they use.
But they just "write" an email and hit "send". They don't know
whether the result is an html email, plain text email, or anything
else about the technical side. To them, it's all just a big bunch of "magic".
And as all the big "providers" seem to have decided that it is more
important that clueless users be able to bold-face, and italicize, and
change the font size, and color, and so forth, they all default to
creating and sending html format emails. The *should* include a
plain-text alternative in the final MIME package that becomes the
email, but sadly, a large number of the providers either don't create
a plain-text alternative, or if they do it is one line saying "your
client can't display this email".
On 2026-10-16, Scott Dorsey wrote:
Nuno Silva <[email protected]d> wrote:
I've just checked one of my outgoing mutt messages. It has
Content-Type. Gnus, the same. Both cases text/plain.
(In fact, how do you specify the encoding without Content-Type?)
You don't specify the encoding at all, you just leave it out. That's
what mailx does.
I see no way this could possibly go wrong.
On 2026-10-16, Scott Dorsey wrote:
(In fact, how do you specify the encoding without Content-Type?)
You don't specify the encoding at all, you just leave it out. That'sI see no way this could possibly go wrong.
what mailx does.
However "plain text" isn't quite plain, there were Mime headers, and
some had quoted-printable, an equal sign followed by hex characters,
e.g. =20 for space.
I went through looking at the source of messages which had content of text/plain. Surprisingly some came from iPhones, some from iPads, one
even from Outlook. However "plain text" isn't quite plain, there were
Mime headers, and some had quoted-printable, an equal sign followed by
hex characters, e.g. =20 for space.
But they did not have an HTML part,--
so the message body was quite small.
On 2026-10-17, Richmond wrote:
I went through looking at the source of messages which had content of
text/plain. Surprisingly some came from iPhones, some from iPads, one
even from Outlook. However "plain text" isn't quite plain, there were
Mime headers, and some had quoted-printable, an equal sign followed by
hex characters, e.g. =20 for space.
That's encoding for transfer, not actual type of the content. Unless you
are using "plain text" as a synonym for US ASCII, you probably need
this.
For that same reason, you likely want the version of Content-Type that
is a MIME header? Or was content encoding and charset standardized
before MIME?
You'll note this news post follows that same norm. Seven bit content
with no MIME headers.
On 2026-10-17, Richmond wrote:
I went through looking at the source of messages which had content of
text/plain. Surprisingly some came from iPhones, some from iPads, one
even from Outlook. However "plain text" isn't quite plain, there were
Mime headers, and some had quoted-printable, an equal sign followed
by hex characters, e.g. =20 for space.
That's encoding for transfer, not actual type of the content. Unless
you are using "plain text" as a synonym for US ASCII, you probably
need this.
. I wote that newsreader myself in Python, but actually it's not
a full featured newsreader, but just the part to send a post.
In comp.misc, Stefan Ram <[email protected]> wrote:
. I wote that newsreader myself in Python, but actually it's not
a full featured newsreader, but just the part to send a post.
The rn/trn newsreader just reads news. To reply by email or to a group,
it invokes a helper tool Rnmail or Pnews. This makes replacing parts in
that way easy. I have modified both of those for my tastes, and even
modified my copy of mailx to use Rnmail as well. I have various syntax
checks and default header adjustments in the same spirit as your
attribution line thing.
Elijah
------
mailx is not natively great about setting headers on outgoing mail
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,142 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 94:07:52 |
| Calls: | 14,704 |
| Calls today: | 2 |
| Files: | 186,497 |
| D/L today: |
2,661 files (886M bytes) |
| Messages: | 2,551,683 |