Subject: Re: [ietf-smtp] Dombox - A Zero Spam Mail System

From: Viruthagiri Thirumavalavan <[email-masked]>
Date: Wed, 2 Oct 2019 11:29:33 +0530

Sorry for the late reply. There was a family function which I had to attend
and I couldn't find enough time to respond.

So how does your system classify this email you're reading right now?
> Is it spam, or bulk mail, or something the user wanted?

We decide whether it's a human-to-human mail or website-related-mail based
on the RCPT TO address type. Not based on sender.

MAIL FROM:<[email-masked]>
250 OK
RCPT TO:<[email-masked]>
250 OK
RCPT TO:<[email-masked]>
250 OK
RCPT TO:<[email-masked]>
250 OK

Mail will be accepted for [email-masked] only if acme.com is
whitelisted in _sad.quora.com => "v=sad1 acme.com -all"
Mail will be accepted for [email-masked] without any issues.
Mail will be accepted for [email-masked] only if acme.com is a
"verified stranger" [MX, SPF, A, +SPF]

So we decide how to proceed based on the RCPT TO address.

The owner of "[email-masked]" agrees that he/she is gonna use that
email address only for "human-to-human" mails when they enable restricted
mode.

While I can warn end users when they enable restricted mode, I can't police
them. What happens when the end user give the address "
[email-masked]" to a mailing list like ietf and enabled restricted
mode? I definitely don't want to send challenge mails to a big mailing
list. That's why I proposed looking for "List-Unsubscribe" headers to
detect non-human mails.

Unlike other C/R based system, we actually send our challenge mails to the
MAIL FROM address. In ietf.org mails, MAIL FROM address is "
[email-masked]". So in most cases, our challenge mails not
gonna cause any issues.

That breaks one of the big advantages of having a fixed address -
> recognizability
> by others.  The address I'm using in this email has been in use for at
> least 2 decades
> now, and allows others to tell that the "me" posting on this list is the
> same "me" posting
> to a Linux mailing list.
> That's why '+' addressing was invented.

You are going to create an isolated mail address only for
website-related-mails. The proper term for "website-related-mails" in our
system is "service-mails". A service is identified via a domain. e.g.
facebook.com

When you give an isolated mail address to a service, generally you don't
care about the issue "recognizability by others". You need this
functionality only in special cases like mailing list, public directory
website etc.

> 1) Many users will *not* think to create a new address for each mailing
> list
> before they subscribe.

Only a tiny percentage of email users use mailing list. Our isolated mail
addresses are created for a service domain. IETF has multiple mailing lists
like SMTP, UTA etc. You don't have to create a separate mail address for
each mailing list. You create only one address here which is tied to the
domain ietf.org

Your statement already says few users are okay with that. These few users
are security conscious folks. So the real question is "How can we educate
the rest?"

I have checked your email address "[email-masked]" in
haveibeenpwned.com Your email address is already found in 10 breaches. You
either used the same password for all those 10 breached sites or used a
unique password for each site. In the latter case, you relied on a software
to remember passwords.

If creating a unique password seems normal to you, then why not creating a
unique email address seems abnormal? Probably because you don't see the
benefits yet. My paper clearly talks about the benefits of having a unique
email address for each website.

My white paper is a plan for the next 10 years. One cannot change the world
overnight. If you take a look at Everett Rogers's "Diffusion of
innovations" theory, he classified the adopters like: innovators, early
adopters, early majority, late majority and laggards.

He defined them like this.

Innovators:
Innovators are willing to take risks, have the highest social status, have
financial liquidity, are social and have closest contact to scientific
sources and interaction with other innovators. Their risk tolerance allows
them to adopt technologies that may ultimately fail. Financial resources
help absorb these failures.

Early adopters:
These individuals have the highest degree of opinion leadership among the
adopter categories. Early adopters have a higher social status, financial
liquidity, advanced education and are more socially forward than late
adopters. They are more discreet in adoption choices than innovators. They
use judicious choice of adoption to help them maintain a central
communication position.

Early Majority:
They adopt an innovation after a varying degree of time that is
significantly longer than the innovators and early adopters. Early Majority
have above average social status, contact with early adopters and seldom
hold positions of opinion leadership in a system

Late Majority:
They adopt an innovation after the average participant. These individuals
approach an innovation with a high degree of skepticism and after the
majority of society has adopted the innovation. Late Majority are typically
skeptical about an innovation, have below average social status, little
financial liquidity, in contact with others in late majority and early
majority and little opinion leadership.

Laggards:
They are the last to adopt an innovation. Unlike some of the previous
categories, individuals in this category show little to no opinion
leadership. These individuals typically have an aversion to change-agents.
Laggards typically tend to be focused on "traditions", lowest social
status, lowest financial liquidity, oldest among adopters, and in contact
with only family and close friends.

So in the early days, we have to focus only on the Innovators and Early
adopters. They will be probably okay with creating a unique mail address as
long as they see the value. Then we have to improve the user experience to
bring rest of the adopters on board.

1a) Sometimes, it's not directly under the user's control.  For example, I
> end
> up using the same address for email from Scouting USA National, and from my
> local troop (because the troop roster is fed from National's records..)

Restricted mode is an optional feature. You don't have to turn it on. Also
my system supports multiple mailboxes. You can enable restricted mode only
to selected mailboxes.

>
> 2) You need to Do The Right Thing if somebody you've never interacted with
> does
> an off-list reply to a post to a list.

If necessary, We can provide an option like "Allow Off-List Replies" in the
mailbox settings. If enabled, the system would treat non-service mails like
human-to-human mails. e.g. You create a dombox address for ietf.org. The
isolated mail address looks like [email-masked]

ietf.org - The system allows all mails from ietf.org + its alias domains by
default.
When "Allow Off-List Replies" mode is OFF, it reject all other domain mails.
When "Allow Off-List Replies" mode is ON, it treats all other domain mails
just like human-to-human mail. i.e. Sender may have to fill CAPTCHA to
deliver mails.

3) If you want your scheme to work in the real world, it needs to play nice
> with browser form autofill.

Page 58 of my paper says,

>
> If the second structure is compatible with 99.99% of the domains, why do we
> need the first one? Why not just stick with the second?
> Well… We need the first structure to provide good user experience.
> Since the first address structure starts with the {Domkey}, we can offer
> autocomplete feature.
> When a user trying to login to a third party website, instead of typing
> the whole
> email address like “[email-masked]”, the user now
> can type
> “testkey123$” and then press tab.
> Our autocomplete feature will behave like this.
> Form Email Field => Alphanumeric characters + The dollar symbol + Tab key
> press =
> capture the current domain and then autocomplete the isolated email address
> Although we can add “Autocomplete” feature in subdomain-based structure
> too, it won’t
> be as good as Dollar-based structure.

I was already focusing on the user experience issues. That's the reason why
we have dollar-based address structures.

Password managers like 1Password offers extensions
<https://chrome.google.com/webstore/detail/1password-extension-deskt/aomjjhallfgjeglblehebfpbcfeobpgk>
for browsers. We can bring such extensions to our system. Password manager
focusing on the "password" field. We are focusing on the "email" field. Our
address structures are not based on random string. It follows a
standardised structure. So you don't have to rely on browser extensions to
remember our email address.

Besides our system already offers two buttons to provide better user
experience. Teleport and Telescribe. Teleport and "SignIn With Apple"
functionality are the same. So Teleport button focus on the user
signups/login without remembering email address and passwords. "Telescribe"
focus on the email newsletter subscriptions.

So... is there actually an architecture or proposal in that 300 page
> document,
> or is it just a cargo-cult collection of things that people have used in
> the
> past, to varying levels of success?

This is what you posted 8 months back when I asked for feedback.

*(a) every aspect we could understand from your writing has already been
> tried and failed, and (b) you've repeatedly proven that you're totally
> unaware of the state of the art on both the spammer side and the
> anti-spammer side. Oh, and (c) you appear to be totally unaware of just how
> little you know.*

It's been 8 months. Nothing changed much. You still have no idea what's in
my paper. Yet posting insulting comments. I'm surprised that you are coming
from an educational background. "Spray and Pray" is not a quality of a
teacher.

To answer your question, If my words have any value, you would have already
gone though my paper.

> And are there any production workload numbers showing that it (a) scales
> and
> (b) actually gets anywhere closer to "Zero" spam than most providers are
> already managing?

I don't have any numbers. But I have an outdated prototype video
<https://www.youtube.com/watch?v=VK2eSfCurx4> which I uploaded last year.
That video may not make any sense unless you read my white paper.

PS: I have gone through the fast-flux technique.

To quote wikipedia, "The basic idea behind Fast flux is to have numerous IP
addresses associated with a single fully qualified domain name, where the
IP addresses are swapped in and out with extremely high frequency, through
changing DNS records".

Since my system is a domain-based reputation system, fresh domains will be
rate limited. Aged domains probably will be blacklisted quickly in the
fast-flux technique.

On Mon, Sep 30, 2019 at 3:47 AM Valdis Klētnieks <[email-masked]>
wrote:

> On Sun, 29 Sep 2019 11:27:15 +0530, Viruthagiri Thirumavalavan said:
>
> > You are talking about bulk mailing here. Our "injection" phase is not
> > designed for bulk mails. That's why we throw this warning when the user
> > enabled restricted mode.
>
> So how does your system classify this email you're reading right now?
>
> Is it spam, or bulk mail, or something the user wanted?
>
> > I want them to create an isolated mail address which would look like
> > [email-masked] and then give this address while signing
> up to
> > ietf mailing list.
>
> That breaks one of the big advantages of having a fixed address -
> recognizability
> by others.  The address I'm using in this email has been in use for at
> least 2 decades
> now, and allows others to tell that the "me" posting on this list is the
> same "me" posting
> to a Linux mailing list.
>
> That's why '+' addressing was invented.
>
> A few user experience issues:
>
> 1) Many users will *not* think to create a new address for each mailing
> list
> before they subscribe.
>
> 1a) Sometimes, it's not directly under the user's control.  For example, I
> end
> up using the same address for email from Scouting USA National, and from my
> local troop (because the troop roster is fed from National's records..)
>
> 2) You need to Do The Right Thing if somebody you've never interacted with
> does
> an off-list reply to a post to a list.
>
> 3) If you want your scheme to work in the real world, it needs to play nice
> with browser form autofill.
>
> So... is there actually an architecture or proposal in that 300 page
> document,
> or is it just a cargo-cult collection of things that people have used in
> the
> past, to varying levels of success?
>
> And are there any production workload numbers showing that it (a) scales
> and
> (b) actually gets anywhere closer to "Zero" spam than most providers are
> already managing?
>
>

-- 
Best Regards,

Viruthagiri Thirumavalavan
Dombox, Inc.

---

From: Hector Santos <[email-masked]>
Date: Fri, 04 Oct 2019 23:59:24 -0400

Viruthagiri,

What would you like to be extracted from your extensive work?  Do you 
have a protocol in mind? a method? an Extended SMTP proposal? a rule 
to be applied at SMTP? At the MSA, the MDA, the MFA (Mail Filtering 
Agent) or the MUA?

There are SMTP documents for Sender Rewriting rules, to rewrite the 
reverse-path.  I recall one was used with the idea to circumvent the 
SPF Node Transition problems when the IP changes but the reverse-path 
domain does not.  The reverse-path is a persistent identity.

Keep in mind that SMTP does not do what your MUA is doing.  SMTP is 
about the transport of mail.  The filtering, the classification, the 
RBM, the once patented concept "Rule-Based Messaging," is generally an 
implementation (product) specific thing and would normally be 
something that separate us.

What you can do, in my opinion, is write an individual draft proposal 
with a status of "Informational" that describes your method.  If you 
can isolate it to a general algorithm without mentioning your product 
and implementation method, i.e., using Chrome extensions for your UI, 
which makes it a web base UI, but your protocol, your rules, would be 
independent of that UI.

This would be one way I see some traction with this. Give us protocol 
rules for handing the SMTP Process Entities which are:

CIP - Connection IP
CDN - Client Domain Name (presented at EHLO/HELO)
RP  - Reverse Path
FP  - Forwarding Path
DATA  RFC5322 payload

Those are the SMTP process parameters.  Present a proposal for using 
these parameters for the betterment of email-kind.

-- 
HLS

On 10/2/2019 1:59 AM, Viruthagiri Thirumavalavan wrote:
> Sorry for the late reply. There was a family function which I had to
> attend and I couldn't find enough time to respond.
>
> We decide whether it's a human-to-human mail or website-related-mail
> based on the RCPT TO address type. Not based on sender.
>
> MAIL FROM:<[email-masked] <mailto:[email-masked]>>
> 250 OK
> RCPT TO:<[email-masked]
> <mailto:[email-masked]>>
> 250 OK
> RCPT TO:<[email-masked] <mailto:[email-masked]>>
> 250 OK
> RCPT TO:<[email-masked] <mailto:[email-masked]>>
> 250 OK
>
> Mail will be accepted for [email-masked]
> <mailto:[email-masked]> only if acme.com
> <http://acme.com> is whitelisted in _sad.quora..com
> <http://sad.quora.com> => "v=sad1 acme.com <http://acme.com> -all"
> Mail will be accepted for [email-masked]
> <mailto:[email-masked]> without any issues.
> Mail will be accepted for [email-masked]
> <mailto:[email-masked]> only if acme.com <http://acme.com> is
> a "verified stranger" [MX, SPF, A, +SPF]
>
> The owner of "[email-masked] <mailto:[email-masked]>"
> agrees that he/she is gonna use that email address only for
> "human-to-human" mails when they enable restricted mode.
>
> While I can warn end users when they enable restricted mode, I can't
> police them. What happens when the end user give the address
> "restricted@example..com <mailto:[email-masked]>" to a mailing
> list like ietf and enabled restricted mode? I definitely don't want to
> send challenge mails to a big mailing list. That's why I proposed
> looking for "List-Unsubscribe" headers to detect non-human mails.
>
> Unlike other C/R based system, we actually send our challenge mails to
> the MAIL FROM address. In ietf.org <http://ietf.org> mails, MAIL FROM
> address is "[email-masked]
> <mailto:[email-masked]>". So in most cases, our challenge
> mails not gonna cause any issues.
>
>     by others.  The address I'm using in this email has been in use
>     for at least 2 decades
>     now, and allows others to tell that the "me" posting on this list
>     is the same "me" posting
>     to a Linux mailing list.
> website-related-mails. The proper term for "website-related-mails" in
> our system is "service-mails". A service is identified via a domain.
> e.g. facebook.com <http://facebook.com>
>
> When you give an isolated mail address to a service, generally you
> don't care about the issue "recognizability by others". You need this
> functionality only in special cases like mailing list, public
> directory website etc.
>
>     1) Many users will *not* think to create a new address for each
>     mailing list
>     before they subscribe.
>
>
> Only a tiny percentage of email users use mailing list. Our isolated
> mail addresses are created for a service domain. IETF has multiple
> mailing lists like SMTP, UTA etc. You don't have to create a separate
> mail address for each mailing list. You create only one address here
> which is tied to the domain ietf.org <http://ietf.org>
>
> Your statement already says few users are okay with that. These few
> users are security conscious folks. So the real question is "How can
> we educate the rest?"
>
> I have checked your email address "[email-masked]
> <mailto:[email-masked]>" in haveibeenpwned.com
> <https://haveibeenpwned.com/> Your email address is already found in
> 10 breaches. You either used the same password for all those 10
> breached sites or used a unique password for each site. In the latter
> case, you relied on a software to remember passwords.
>
> If creating a unique password seems normal to you, then why not
> creating a unique email address seems abnormal? Probably because you
> don't see the benefits yet. My paper clearly talks about the benefits
> of having a unique email address for each website.
>
> My white paper is a plan for the next 10 years. One cannot change the
> world overnight. If you take a look at Everett Rogers's "Diffusion of
> innovations" theory, he classified the adopters like: innovators,
> early adopters, early majority, late majority and laggards.
>
> Innovators are willing to take risks, have the highest social status,
> have financial liquidity, are social and have closest contact to
> scientific sources and interaction with other innovators. Their risk
> tolerance allows them to adopt technologies that may ultimately fail.
> Financial resources help absorb these failures.
>
> Early adopters:
> These individuals have the highest degree of opinion leadership among
> the adopter categories. Early adopters have a higher social status,
> financial liquidity, advanced education and are more socially forward
> than late adopters. They are more discreet in adoption choices than
> innovators. They use judicious choice of adoption to help them
> maintain a central communication position.
>
> Early Majority:
> significantly longer than the innovators and early adopters. Early
> Majority have above average social status, contact with early adopters
> and seldom hold positions of opinion leadership in a system
>
> Late Majority:
> They adopt an innovation after the average participant. These
> individuals approach an innovation with a high degree of skepticism
> and after the majority of society has adopted the innovation. Late
> Majority are typically skeptical about an innovation, have below
> average social status, little financial liquidity, in contact with
> others in late majority and early majority and little opinion leadership.
>
> Laggards:
> leadership. These individuals typically have an aversion to
> change-agents. Laggards typically tend to be focused on "traditions",
> lowest social status, lowest financial liquidity, oldest among
> adopters, and in contact with only family and close friends.
>
> So in the early days, we have to focus only on the Innovators
> and Early adopters. They will be probably okay with creating a unique
> mail address as long as they see the value. Then we have to improve
> the user experience to bring rest of the adopters on board.
>
>     1a) Sometimes, it's not directly under the user's control.  For
>     example, I end
> Restricted mode is an optional feature. You don't have to turn it on.
> Also my system supports multiple mailboxes. You can enable restricted
> mode only to selected mailboxes.
>
>
>     2) You need to Do The Right Thing if somebody you've never
>     interacted with does
> If necessary, We can provide an option like "Allow Off-List Replies"
> in the mailbox settings.. If enabled, the system would treat
> non-service mails like human-to-human mails. e.g. You create a dombox
> address for ietf.org <http://ietf.org>. The isolated mail address
> looks like ietf.org@test123..example.com
> <mailto:[email-masked]>
>
> ietf.org <http://ietf.org> - The system allows all mails from ietf.org
> <http://ietf.org> + its alias domains by default.
> When "Allow Off-List Replies" mode is ON, it treats all other domain
> mails just like human-to-human mail. i.e. Sender may have to fill
> CAPTCHA to deliver mails.
>
>     Since the first address structure starts with the {Domkey}, we can
>     offer autocomplete feature.
>     When a user trying to login to a third party website, instead of
>     typing the whole
>     email address like “[email-masked]
>     <mailto:[email-masked]>”, the user now can type
>     Form Email Field => Alphanumeric characters + The dollar symbol +
>     Tab key press =
>     Although we can add “Autocomplete” feature in subdomain-based
>     structure too, it won’t
> I was already focusing on the user experience issues. That's the
> reason why we have dollar-based address structures.
>
> for browsers. We can bring such extensions to our system. Password
> manager focusing on the "password" field. We are focusing on the
> "email" field. Our address structures are not based on random string.
> It follows a standardised structure. So you don't have to rely on
> browser extensions to remember our email address.
>
> signups/login without remembering email address and passwords.
> "Telescribe" focus on the email newsletter subscriptions.
>
>     So... is there actually an architecture or proposal in that 300
>     page document,
>     or is it just a cargo-cult collection of things that people have
>     used in the
>     /(a) every aspect we could understand from your writing has
>     already been tried and failed, and (b) you've repeatedly proven
>     that you're totally unaware of the state of the art on both the
>     spammer side and the anti-spammer side.. Oh, and (c) you appear to
>     be totally unaware of just how little you know./
>
>
> It's been 8 months. Nothing changed much. You still have no idea
> what's in my paper. Yet posting insulting comments. I'm surprised that
> you are coming from an educational background. "Spray and Pray" is not
> a quality of a teacher.
>
> To answer your question, If my words have any value, you would have
> already gone though my paper.
>
>     And are there any production workload numbers showing that it (a)
>     scales and
> <https://www.youtube.com/watch?v=VK2eSfCurx4> which I uploaded last
> year. That video may not make any sense unless you read my white paper.
>
> To quote wikipedia, "The basic idea behind Fast flux is to have
> numerous IP addresses associated with a single fully qualified domain
> name, where the IP addresses are swapped in and out with extremely
> high frequency, through changing DNS records".
>
> Since my system is a domain-based reputation system, fresh domains
> will be rate limited. Aged domains probably will be blacklisted
> quickly in the fast-flux technique.
>
> On Mon, Sep 30, 2019 at 3:47 AM Valdis Klētnieks
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     >[email-masked]
>     <mailto:[email-masked]> and then give this address
>     while signing up to
>     > ietf mailing list.
>
>     by others.  The address I'm using in this email has been in use
>     for at least 2 decades
>     now, and allows others to tell that the "me" posting on this list
>     is the same "me" posting
>     to a Linux mailing list.
>
>     1) Many users will *not* think to create a new address for each
>     mailing list
>     before they subscribe.
>
>     1a) Sometimes, it's not directly under the user's control.  For
>     example, I end
>     2) You need to Do The Right Thing if somebody you've never
>     interacted with does
>     So... is there actually an architecture or proposal in that 300
>     page document,
>     or is it just a cargo-cult collection of things that people have
>     used in the
>     And are there any production workload numbers showing that it (a)
>     scales and

---

From: Дилян Палаузов <[email-masked]>
Date: Sat, 05 Oct 2019 11:35:53 +0000

Hello,

notwithstanding the usefulness of the ideas, provided that new rules are supposed to be applied at SMTP level right
after the RCPT TO:, and let each recipient tweak these rules, based on destination address and other criteria, the next
step would be to extend Sieve to accommodate these filtering rules.

Sieve can already deal with the fact that a single (natural) recipient can have several addresses and apply different
logic based on the envelope destination for that natural recipient.  But it cannot check directly DNS.  It could check
however over “external lists” if DNS/SPF matches (but this could be done also by matching against the Authentication-
Results header).

Has anybody tried to parse the Authentication-Results header in Sieve?  Does it work?

Perhaps you can write guidelines how to use Sieve to perform (further) per recipient rules, reusing the capabilities the
language already has, possibly extending the language, is the way to go.

Or, adding new checks, that are inserted in the AR header.

Or, if the concepts can be applied independent of each other, describe each idea in a separate document (internet
draft).

Greetings
  Дилян

---

From: Viruthagiri Thirumavalavan <[email-masked]>
Date: Sat, 5 Oct 2019 19:24:06 +0530

Hello Hector,

Thanks for the helpful input.

What would you like to be extracted from your extensive work?

I actually started to propose things from my work a long time back. Back in
Jan 2019, I proposed "SMTP Over TLS on Port 26 - Implicit TLS Proposal" in this
mailing list
<https://www.mhonarc.org/archive/html/ietf-smtp/2019-01/msg00001.html>.

Original Proposal:
https://medium.com/@Viruthagiri/smtp-over-tls-on-port-26-efc67e8a99ce
Companion Article:
https://medium.com/@Viruthagiri/smtp-ports-25-vs-587-vs-465-de1046f57636

At that time, only a few folks supported my proposal.

It's actually a very simple hack. You add a prefix in the MX record and
then protect it with DNSSEC.

(1) STARTTLS Prefix

Use this prefix only to deal with STARTTLS downgrade issue.

e.g. mx1.example.com should be prefixed like starttls-mx1.example.com.

Where “starttls-” says “Our port 25 supports Opportunistic TLS. So if
STARTTLS command not found in the EHLO response or certificate is invalid,
then drop the connection”.

(2) SMTPS Prefix

Use this prefix if you wanna support Implicit TLS on port 26 and
Opportunistic TLS on port 25.

e.g. mx1.example.com should be prefixed like smtps-mx1.example.com.

Where “smtps-” says “We prefer if you connect to our SMTPS in port 26. But
we also accept mails in port 25. And our port 25 supports Opportunistic
TLS. So if STARTTLS command not found in the EHLO response or certificate
is invalid, then drop the connection”.

-------

I dropped my “starttls-” prefix proposal because some folks said my
solution is not compatible with servers that use only A record for
accepting mails. [This is not a valid rationale. A server that support only
A record for accepting mails still staying in the 80s. So security is least
of their concerns. Rejecting a solution that's compatible with 99.9% of the
servers in favour of 0.1% servers is not a valid rationale in my opinion.]

I dropped my "smtps-" prefix proposal because some folks don't want to
waste a port for my solution. [On an abstract level, Implicit TLS is better
than Opportunistic TLS. If there is really an innovation happens in the
future in the Implicit TLS, then SMTP is gonna miss that boat]

Just to be clear, I'm not saying that all my proposal has merits. I'm sure
there may be flaws. All I'm looking for is a set of valid rationale when my
proposal is getting rejected. So I can improve the proposal by fixing the
flaws. If it is really a dead end, then I can kill it.

-------

In my opinion, a mail protocol must stay on its course. It should not rely
on third party protocols like HTTPS to provide security. I would be really
grateful if anyone of you take over my STARTTLS and SMTPS prefix proposal
and explore the viability of that solution. Feel free to copy the content
from my blog posts for the IETF draft.

https://medium.com/@Viruthagiri/smtp-over-tls-on-port-26-efc67e8a99ce
https://medium.com/@Viruthagiri/smtp-ports-25-vs-587-vs-465-de1046f57636

On Sat, Oct 5, 2019 at 9:29 AM Hector Santos <[email-masked]> wrote:

> > <
> https://chrome.google.com/webstore/detail/1password-extension-deskt/aomjjhallfgjeglblehebfpbcfeobpgk
> >

-- 
Best Regards,

---

From: Viruthagiri Thirumavalavan <[email-masked]>
Date: Sat, 5 Oct 2019 19:39:45 +0530

Hi Дилян,

My apologies. I don't have experience with Sieve. But I'll take a look at
it.

On Sat, Oct 5, 2019 at 5:05 PM Дилян Палаузов <[email-masked]>
wrote:

> Hello,
>
> notwithstanding the usefulness of the ideas, provided that new rules are
> supposed to be applied at SMTP level right
> after the RCPT TO:, and let each recipient tweak these rules, based on
> destination address and other criteria, the next
> Sieve can already deal with the fact that a single (natural) recipient can
> have several addresses and apply different
> logic based on the envelope destination for that natural recipient.  But
> it cannot check directly DNS.  It could check
> however over “external lists” if DNS/SPF matches (but this could be done
> also by matching against the Authentication-
> Results header).
>
> Perhaps you can write guidelines how to use Sieve to perform (further) per
> recipient rules, reusing the capabilities the
> Or, if the concepts can be applied independent of each other, describe
> each idea in a separate document (internet
> draft).
>
> Greetings
>   Дилян
>

-- 
Best Regards,

---

From: Hector Santos <[email-masked]>
Date: Sat, 05 Oct 2019 17:07:53 -0400

I don't know about this "SMTP OVER TLS" proposal but I do recall it 
posted. If you had a IETF draft, more than likely I clicked it.  It 
helps with the potential interest. I am a practical and conservative 
person.  With SMTP, we already have a secured comm I/O channel method 
in both ex/im-plicit mode.  What more is needed?  I don't know.  What 
problem was your proposal solving? (rhetorical question).

Encryption is important and its also becoming mandatory, and in an 
exclusive case, I am seeing encrypted channel degradation due to the 
increased packet security inspection  overhead at the ISP and federal 
level.   Why?  Here is my conclusion:

1) Higher overhead security proxies are assuming HTTP 1.1 (persistent 
connections) web server operations,

2) Higher overhead security proxies are assuming CA-signed certificates.

What I am seeing this at the HTTP/HTTPS level.  Fortunately, in 
general, 3rd party trusted encryption  was not enforced at the SMTP 
level. A big reason for that is because the Mail Industry was not 
locked down by 2-3 vendors, like in the browser market, with their 
enforced direction to secured 3rd party trust - and scare users.

We don't have that with SMTP. Thank g-d!  What are the pros and cons? 
  Long discussed.  Big elephant in the room type of issues.

-- 
HLS

On 10/5/2019 9:54 AM, Viruthagiri Thirumavalavan wrote:
>
> I actually started to propose things from my work a long time back.
> Back in Jan 2019, I proposed "SMTP Over TLS on Port 26 - Implicit TLS
> Proposal" in this mailing list
> It's actually a very simple hack. You add a prefix in the MX record
> and then protect it with DNSSEC..
>
> (1) STARTTLS Prefix
>
> e.g. mx1.example.com <http://mx1.example.com> should be prefixed like
> starttls-mx1.example.com <http://starttls-mx1.example.com>.
>
> STARTTLS command not found in the EHLO response or certificate is
> invalid, then drop the connection”.
>
> (2) SMTPS Prefix
>
> e.g. mx1.example.com <http://mx1.example.com> should be prefixed like
> smtps-mx1.example.com <http://smtps-mx1.example.com>.
>
> Where “smtps-” says “We prefer if you connect to our SMTPS in port 26.
> But we also accept mails in port 25. And our port 25 supports
> Opportunistic TLS. So if STARTTLS command not found in the EHLO
> response or certificate is invalid, then drop the connection”.
>
> -------
>
> accepting mails. [This is not a valid rationale. A server that support
> only A record for accepting mails still staying in the 80s. So
> security is least of their concerns. Rejecting a solution that's
> compatible with 99.9% of the servers in favour of 0.1% servers is not
> a valid rationale in my opinion.]
>
> waste a port for my solution. [On an abstract level, Implicit TLS is
> better than Opportunistic TLS. If there is really an innovation
> happens in the future in the Implicit TLS, then SMTP is gonna miss
> that boat]
>
> Just to be clear, I'm not saying that all my proposal has merits. I'm
> sure there may be flaws. All I'm looking for is a set of valid
> rationale when my proposal is getting rejected. So I can improve the
> proposal by fixing the flaws. If it is really a dead end, then I can
> kill it.
>
> -------
>
> In my opinion, a mail protocol must stay on its course. It should not
> rely on third party protocols like HTTPS to provide security. I would
> be really grateful if anyone of you take over my STARTTLS and SMTPS
> prefix proposal and explore the viability of that solution. Feel free
> to copy the content from my blog posts for the IETF draft.
>
> <https://medium..com/@Viruthagiri/smtp-over-tls-on-port-26-efc67e8a99ce>
> On Sat, Oct 5, 2019 at 9:29 AM Hector Santos <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Viruthagiri,
>
>     > MAIL FROM:<[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>     > 250 OK
>     > RCPT TO:<[email-masked] <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>>
>     > 250 OK
>     > RCPT TO:<[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>     > 250 OK
>     > RCPT TO:<[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>     > 250 OK
>     >
>     > Mail will be accepted [email-masked] <mailto:[email-masked]>
>     > <mailto:[email-masked]
>     <mailto:[email-masked]>> only if acme.com
>     <http://acme.com>
>     > <http://sad.quora.com> => "v=sad1 acme.com <http://acme.com>
>     <http://acme.com> -all"
>     > Mail will be accepted [email-masked] <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>> without any issues.
>     > Mail will be accepted [email-masked] <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>> only if
>     acme.com <http://acme.com> <http://acme.com> is
>     > The owner of "[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>"
>     > "restricted@example..com <mailto:[email-masked] <mailto:[email-masked]>>" to a mailing
>     > the MAIL FROM address. Inietf.org <http://ietf.org> <http://ietf.org> mails, MAIL FROM
>     > address is "[email-masked] <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>".
>     So in most cases, our challenge
>     > e.g.facebook.com <http://facebook.com> <http://facebook.com>
>     >
>     > which is tied to the domainietf.org <http://ietf.org> <http://ietf.org>
>     >
>     > I have checked your email address "[email-masked] <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>" in
>     haveibeenpwned.com <http://haveibeenpwned..com>
>     > address forietf.org <http://ietf.org> <http://ietf.org>. The isolated mail
>     address
>     > looks like ietf.org@test123..example.com <http://example.com>
>     > <mailto:[email-masked] <mailto:[email-masked]>>
>     >
>     >ietf.org <http://ietf.org> <http://ietf.org> - The system allows
>     all mails from ietf.org <http://ietf.org>
>     >     email address like “[email-masked] <mailto:[email-masked]>
>     >     <mailto:[email-masked] <mailto:twitter.com@domboxmail..com>>”,
>     the user now can type
>     > year. That video may not make any sense unless you read my white paper..
>     >
>     > <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>     wrote:
>     >
>     >     >[email-masked] <mailto:[email-masked]>
>     >     <mailto:[email-masked]
>     <mailto:[email-masked]>> and then give this address
>     >     while signing up to
>     >     > ietf mailing list.
>     >
> _______________________________________________
> ietf-smtp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-smtp
>

---

From: Viruthagiri Thirumavalavan <[email-masked]>
Date: Sun, 6 Oct 2019 13:34:45 +0530

>
> With SMTP, we already have a secured comm I/O channel method

SMTP has port 465 for Implicit TLS. Port 465 was discontinued in the late
90’s in favour of STARTTLS extension. Two decades later that port got
reassigned to "Message Submission" in 2018.

IANA details for port 465 is as follows.

Service Name: submissions
Port Number: 465
Transport Protocol: tcp
Description:  Message Submission over TLS protocol
Registration Date: 2017-12-12

So the “submission” part supports Implicit TLS. But “Transfer” mode is
still missing the “Implicit TLS”. We can't use the same port 465 for
"Transfer" mode since all ISPs wanna block only direct-to-mx connections to
prevent outgoing spam and not the message submission connections. So there
will be a conflict if we use port 465 for both "submission" and "transfer".
That's why I proposed a new port 26.

-------------

My "starttls-" prefix proposal trying to solve the same problem what DANE
and MTA-STS trying to solve. But my proposal does that in a very simple
way.

https://tools.ietf.org/html/rfc8461
https://tools.ietf.org/html/rfc7672

There are other proposals too.

https://starttls-everywhere.org/
https://tools.ietf.org/id/draft-ietf-uta-smtp-require-tls-09.html

-----

DANE requires DNSSEC to work. It also requires DNS service providers to
support a new DNS record type called TLSA. This is how
<https://www.huque.com/bin/gen_tlsa> a TLSA record generator looks like. So
DANE is complicated for an average end user.

As for MTA-STS, It requires a HTTPS server with a valid SSL certificate. A
domain owner who rely on Google for hosting his/her mails, now need to buy
a hosting package and setup a HTTPS server for their mail security.

To quote MTA-STS RFC,

"The primary motivation of MTA-STS is to provide a mechanism for domains to
ensure transport security even when deploying DNSSEC is undesirable or
impractical."

So MTA-STS seem like it got introduced to avoid DANE/DNSSEC. Gmail
already started
to support
<https://gsuiteupdates.googleblog.com/2019/04/gmail-making-email-more-secure-with-mta-sts.html>
MTA-STS.

>From what I understood so far, big companies don't want to support
DANE/DNSSEC due to government involvement in the TLD. That's why they are
going for MTA-STS.

If you want DNSSEC to become popular, then it should be recommended by
these big companies even if they don't support it for their personal
reasons.

-------

Now let me explain my solution with an example.

Acme.com is a Google business mail user. Acme hosting all their mails in
Google. Google asks acme.com to point their MX to "aspmx.l.google.com"

In my solution, Google don't have to support DNSSEC in their servers. They
have to add a prefix like "starttls-aspmx.l.google.com" and then ask
acme.com to point their MX to "starttls-aspmx.l.google.com". Now Google has
to just advice acme.com to enable DNSSEC. They don't have to force acme.com
to configure DNSSEC. They just have to recommend it.

When a client fetch MX record of acme.com, the response will be "
starttls-aspmx.l.google.com". If acme.com enabled DNSSEC, that means that
MX record is safe from MiTM attacks. Now the client has to connect to "
starttls-aspmx.l.google.com" and then validate the SSL certificate before
transferring the message. That's all.

So my solution offers simplicity.

To quote a person regarding my starttls prefix proposal,

"Honestly, you feel very highly of your work in which any of us do in this
field"

Ultimately, that's what I'm after.

On Sun, Oct 6, 2019 at 2:38 AM Hector Santos <hsantos=
[email-masked]> wrote:

> <mailto:[email-masked]>
> >     > When "Allow Off-List Replies" mode is OFF, it reject all other
> domain
> >     > mails.
> >     >     3) If you want your scheme to work in the real world, it needs
> to
> >     >     play nice
> >     >     If the second structure is compatible with 99.99% of the
> domains,
> >     >     why do we
> <mailto:[email-masked]>
> >     >     3) If you want your scheme to work in the real world, it needs
> to
> >     >     play nice

-- 
Best Regards,

---

From: Keith Moore <[email-masked]>
Date: Sun, 6 Oct 2019 08:13:38 -0400

There's a reason that DANE requires DNSSEC.    DNS responses are easily 
faked by an attacker using a variety of means.   From my reading of your 
proposal, it also requires DNSSEC, though you don't word it that 
strongly.   If an MX record with target smtps- or starttls- isn't signed 
using DNSSEC, it's not clear that the client should trust the smtps- or 
starttls- prefix, and that the client should drop mail that can't be 
relayed that way.   At the very least an analysis is needed that shows 
that the threats presented by faked DNS responses is no worse with 
smtps- or starttls- records than with ordinary MX records.   (Taken by 
itself the threat of a DoS attack using faked DNS responses seems to be 
worse with your proposal, but IMO the analysis needs to consider the 
overall spectrum of threats including the threat of eavesdropping on 
unencrypted SMTP transmissions.)

Or maybe there's another way besides DNSSEC to assure the validity of 
the DNS response.   Maybe, for example, the SMTP client can rely on the 
response as being valid if it uses DoT or DoH to do the query and the 
server certificate is (a) valid and (b) matches the DNS name of the zone 
being queried.   (I suspect the real trick, just as with any use of TLS 
on an outsourced server, is trusting the DoT or DoH hosting provider to 
securely manage the server certificate.   But at least this is not a new 
problem.)

(Given that there are currently huge tussles over use of DoH, 
recommending DoT might be less controversial.)

Regarding the use of IDNs, the easiest way to address this is to not use 
IDNs as the targets of MX records - since users don't generally see the 
MX records anyway.   But another fix would be to have the "smtps" or 
"starttls" tag be a separate DNS label rather than a prefix to another 
label.

Keith

p.s. It is indeed unfortunate that DNSSEC is so hard to deploy. From my 
perspective I haven't seen that governments are the problem though, but 
rather lack of support from registrars, and/or perhaps that there's not 
enough information provided to zone administrators as to how to do it.   
More work is definitely needed in this area.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sun, 6 Oct 2019 16:14:52 +0200

On Sunday 6 October 2019 14:13:38 CEST, Keith Moore wrote:
> Regarding the use of IDNs, the easiest way to address this is 
> to not use IDNs as the targets of MX records - since users don't 
> generally see the MX records anyway.

Which is a good idea for another reason — the MX target is generally the 
same as or similar to the name used as EHLO argument, and EHLO is issued 
before the sender knows whether the received supports SMTPUTF8.

But I don't know whether it's reason enough to get a non-IDN domain. IMO 
it's reason enough to use a non-IDN domain for mail servers if one has such 
a domain, but registering another domain? maybe not. And for that reason, 
perhaps not something that can be advised in an RFC.

Arnt

---

From: Keith Moore <[email-masked]>
Date: Sun, 6 Oct 2019 10:34:37 -0400

On 10/6/19 10:14 AM, Arnt Gulbrandsen wrote:

>> Regarding the use of IDNs, the easiest way to address this is to not 
>> use IDNs as the targets of MX records - since users don't generally 
>> see the MX records anyway.
>
> Which is a good idea for another reason — the MX target is generally 
> the same as or similar to the name used as EHLO argument, and EHLO is 
> issued before the sender knows whether the received supports SMTPUTF8.

I can't find any justification at all for ever using the UTF-8 form of 
an IDN in EHLO.   IMO it should be a MUST NOT.

> But I don't know whether it's reason enough to get a non-IDN domain. 
> IMO it's reason enough to use a non-IDN domain for mail servers if one 
> has such a domain, but registering another domain? maybe not. And for 
> that reason, perhaps not something that can be advised in an RFC.

Well, at least for this specific proposal, the only place that it 
matters whether the name is an IDN is whether the leftmost facet of the 
name is not ASCII and therefore requires encoding.   It won't confuse 
SMTP clients if other facets of the name are non-ASCII.

My real point was, if you're going to encode something new in a DNS 
name, try to avoid introducing dependencies on the way that IDNs are 
encoded, because it's likely to bite back sooner or later.

Keith

---

From: Viruthagiri Thirumavalavan <[email-masked]>
Date: Sun, 6 Oct 2019 21:33:42 +0530

Thanks Keith for the excellent insight.

You have made some excellent points. Yes, "a separate DNS label" is much
cleaner than using a prefix. Thanks for the suggestion.

You are right. My solution needs DNSSEC to work properly. Honestly, I have
no idea about the future of DNSSEC. Especially when big companies are
against DNSSEC. Maybe another standard like DNSCurve would replace DNSSEC
in the future. So the future of DNSSEC is still questionable.

When I prepared my proposal, my intention was focusing only on the
"signaling" part. That's because these MX records can also provided by
third party mail hosting like Google. Besides I don't want to force a
complicated technology just to support my solution. In any case, a plain
prefix-based MX record is pointless without DNSSEC or its alternatives.

Clients should treat a plain prefix-based MX record just like any other MX
record until DNSSEC support available for that domain. I think DNS Over TLS
is a good suggestion. If we can't go with the DNSSEC route, the we should
go with DoT route as you suggested.

Thanks

-- 
Best Regards,

---

From: "John Levine" <[email-masked]>
Date: 6 Oct 2019 12:36:58 -0400

>an IDN in EHLO.   IMO it should be a MUST NOT.

Ahem.  See RFC 6531, sec 3.7.1.

>> But I don't know whether it's reason enough to get a non-IDN domain. 

I should hope not.  Any mail server that doesn't properly handle ASCII
mail to and from addresses that contain A-labels is pretty badly
broken.

R's,
John

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sun, 6 Oct 2019 20:18:44 +0200

On Sunday 6 October 2019 16:34:37 CEST, Keith Moore wrote:
> I can't find any justification at all for ever using the UTF-8 
> form of an IDN in EHLO.   IMO it should be a MUST NOT.

It is a MUST NOT.

IMO it also is a bug magnet, and it's best to step out of its way by using 
all-ASCII server names both in EHLO and in Received fields. I might be 
wrong, of course.

Arnt

---

From: Keith Moore <[email-masked]>
Date: Sun, 6 Oct 2019 14:25:46 -0400

On 10/6/19 2:18 PM, Arnt Gulbrandsen wrote:

>> I can't find any justification at all for ever using the UTF-8 form 
>> of an IDN in EHLO.   IMO it should be a MUST NOT.
>
> It is a MUST NOT.
>
> IMO it also is a bug magnet, and it's best to step out of its way by 
> using all-ASCII server names both in EHLO and in Received fields. I 
> might be wrong, of course. 

Well, for what it's worth, I agree with you.

Keith

---

From: Jeremy Harris <[email-masked]>
Date: Sun, 6 Oct 2019 22:48:20 +0100

> That's why I proposed a new port 26.

An alternative might be to use TCP ENO (RFC 8547) and tcpcrypt
(RFC 8548), sitting on port 25 ?
-- 
Cheers,
  Jeremy

---

From: John C Klensin <[email-masked]>
Date: Sun, 06 Oct 2019 20:40:39 -0400

--On Sunday, 06 October, 2019 10:34 -0400 Keith Moore
<[email-masked]> wrote:

> Well, at least for this specific proposal, the only place that
> it matters whether the name is an IDN is whether the leftmost
> facet of the name is not ASCII and therefore requires
> encoding.   It won't confuse SMTP clients if other facets of
> the name are non-ASCII.

Keith, I'm not sure what you are trying to say.  Except in EHLO
and the DNS itself, where, as John Levine pointed, A-labels are
required, SMTP won't allow _anything_ other than ASCII in any
domain name or mailbox address in the envelope with no
distinction between the leftmost label and any other one, unless
SMTPUTF8 is offered and accepted.  For applications using IDNA,
which include SMTP if SMTPUTF8 is in used, the IDNA specs
prohibit the use of any domain name label that starts with
letter-letter-hyphen-hyphen to allow for future extensions.  So,
if I understand the cases you are talking about above, they are
already prohibited.

> My real point was, if you're going to encode something new in
> a DNS name, try to avoid introducing dependencies on the way
> that IDNs are encoded, because it's likely to bite back sooner
> or later.

Right.  But the only case in which that could arise would
involve an application that did not support IDNA and that
happened to choose a label syntax that started with "xn--" or
even that used a letter-letter-hyphen-hyphen form for something
else and without updating the IDNA specs.  IDNA, at least in the
ACE form with that prefix, has been with us for close to 17
years now.   Certainly there are embedded applications that are
older than that which don't support (some of those are old
enough that they are still using HELO, and that is more than a
quarter-century).  Any contemporary application that invents a
new label prefix that looks like IDNA is almost certainly an
attack or someone being so clever as to amount to blatant
stupidity.

   john

---

From: Keith Moore <[email-masked]>
Date: Sun, 6 Oct 2019 20:48:58 -0400

On 10/6/19 8:40 PM, John C Klensin wrote:

> Keith, I'm not sure what you are trying to say.

I'm specifically referring to [email-masked]'s proposal to signal a 
MX's willingness to do TLS by putting a prefix (smtps- or starttls-) on 
the target of an MX record.  One minor complication crops up if the 
first facet of an IDN requires ASCII encoding. So an SMTP client can't 
merely look for those prefixes in the MX record target, it has to look 
for the encoded form of those prefixes also.   A possible fix to make 
the implementation simpler would be to prepend smtps. or starttls.  (or 
some other magic token) thus causing that facet of the IDN to not 
require encoding.

Keith

---

From: John C Klensin <[email-masked]>
Date: Sun, 06 Oct 2019 22:07:21 -0400

--On Sunday, 06 October, 2019 20:48 -0400 Keith Moore
<[email-masked]> wrote:

>>> Well, at least for this specific proposal, the only place
>>> that it matters whether the name is an IDN is whether the
>>> leftmost facet of the name is not ASCII and therefore
>>> requires encoding.   It won't confuse SMTP clients if
>>> other facets of the name are non-ASCII.
> I'm specifically referring to [email-masked]'s proposal to
> signal a MX's willingness to do TLS by putting a prefix
> (smtps- or starttls-) on the target of an MX record.  One
> minor complication crops up if the first facet of an IDN
> requires ASCII encoding. So an SMTP client can't merely look
> for those prefixes in the MX record target, it has to look for
> the encoded form of those prefixes also.   A possible fix to
> make the implementation simpler would be to prepend smtps. or
> starttls.  (or some other magic token) thus causing that
> facet of the IDN to not require encoding.

Ah, ok.  Makes sense.  Probably even better to try to treat this
as a service, e.g., make the leftmost label "_smtps" or even
"_dombox" or the like.  I haven't thought deeply about it, but
that model, which is reasonably well-defined, should work as
long as _dombox.mail.example.com. is treated as the name of a
host because, in the DNS record were, e.g.,
   
   mysystem.example.com. MX 0 _dombox.mail.example.com.

it has to be an alias for something else or if it has to be
parsed in a special way, that would probably violate the SMTP
rule about MX targets.

thanks,
  john

---

From: Viruthagiri Thirumavalavan <[email-masked]>
Date: Mon, 7 Oct 2019 19:06:59 +0530

Hi Jeremy,

Thanks for the suggestion.

TCP ENO (RFC 8547) abstract says,

Despite growing adoption of TLS, a significant fraction of TCP traffic on
> the Internet remains unencrypted. The persistence of unencrypted traffic
> can be attributed to at least two factors. First, some legacy protocols
> lack a signaling mechanism (such as a STARTTLS command) by which to convey
> support for encryption, thus making incremental deployment impossible.
> Second, legacy applications themselves cannot always be upgraded and
> therefore require a way to implement encryption transparently entirely
> within the transport layer. The TCP Encryption Negotiation Option (TCP-ENO)
> addresses both of these problems through a new TCP option kind providing
> out-of-band, fully backward-compatible negotiation of encryption.

 TCPCrypt home page <http://www.tcpcrypt.org/> says,

While weaker by default, Tcpcrypt is more realistic for universal
> deployment.

So it seems like TCP ENO and TCPCrypt are well suited for protocols where
STARTTLS is not possible.

Thanks

-- 
Best Regards,

---

From: Viruthagiri Thirumavalavan <[email-masked]>
Date: Tue, 8 Oct 2019 15:15:33 +0530

>
> I would just like to hear from others with more experience - which of the
> existing services are doing it right, and how do they do it?

Hi David,

This is a good read if you are still interested.

https://moderncrypto.org/mail-archive/messaging/2014/000780.html

On Sun, Sep 29, 2019 at 6:26 PM David MacQuigg <[email-masked]> wrote:

> Changing the subject to minimize discussion of technical detail.  I would
> just like to hear from others with more experience - which of the existing
> services are doing it right, and how do they do it?  The goal is near-zero
> spam in my inbox (1% is my threshold of annoyance), and no lost emails.
> Also, please disclose if you have any connection with the service.
>
> I have been using gmail for the last few years.  No connection other than
> as a client.  Spam in my inbox is maybe one in 200.  I have noticed one or
> two lost emails in the last year.  Before that I was not aware of any.
> Note:  I don't count as spam any that appear on a separate tab labeled
> "Promotions".  I don't count as "lost" any that appear in my spam bucket.
> How do they do it?  I guess they have a very complete whitelist of
> senders.  They also have an icon "Report spam" at they top of their
> webpage, which I assume is their main source of rapid feedback.
>
> My wife uses Yahoo, and she is seeing a lot more spam, but not enough to
> motivate her to change services.  I guess they also use a whitelist.
>

-- 
Best Regards,

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 10 Oct 2019 00:58:00 -0400

> On Oct 6, 2019, at 10:07 PM, John C Klensin <[email-masked]> wrote:
> 

That's an invalid hostname, and I would not be surprised to
find a non-trivial number of MTAs that are not only unable to
deliver email to a domain with MX hosts of that form, but may
even reject inbound mail when a sending domain has no valid MX
hosts.

-- 
	Viktor.