|
Re: [ietf-smtp] Dombox - A Zero Spam Mail System
2019-10-05 16:08:09
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
<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 <http://mx1.example.com> should be prefixed like
starttls-mx1.example.com <http://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 <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”.
-------
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-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 <hsantos(_at_)isdg(_dot_)net
<mailto:hsantos(_at_)isdg(_dot_)net>> wrote:
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.
>
> 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:<someuser(_at_)acme(_dot_)com
<mailto:someuser(_at_)acme(_dot_)com>
<mailto:someuser(_at_)acme(_dot_)com <mailto:someuser(_at_)acme(_dot_)com>>>
> 250 OK
> RCPT TO:<quora(_dot_)com(_at_)test123(_dot_)example(_dot_)com
<mailto:quora(_dot_)com(_at_)test123(_dot_)example(_dot_)com>
> <mailto:quora(_dot_)com(_at_)test123(_dot_)example(_dot_)com
<mailto:quora(_dot_)com(_at_)test123(_dot_)example(_dot_)com>>>
> 250 OK
> RCPT TO:<normal(_at_)example(_dot_)com
<mailto:normal(_at_)example(_dot_)com>
<mailto:normal(_at_)example(_dot_)com
<mailto:normal(_at_)example(_dot_)com>>>
> 250 OK
> RCPT TO:<restricted(_at_)example(_dot_)com
<mailto:restricted(_at_)example(_dot_)com>
<mailto:restricted(_at_)example(_dot_)com
<mailto:restricted(_at_)example(_dot_)com>>>
> 250 OK
>
> Mail will be accepted forquora(_dot_)com(_at_)test123(_dot_)example(_dot_)com
<mailto:quora(_dot_)com(_at_)test123(_dot_)example(_dot_)com>
> <mailto:quora(_dot_)com(_at_)test123(_dot_)example(_dot_)com
<mailto:quora(_dot_)com(_at_)test123(_dot_)example(_dot_)com>> only if
acme.com
<http://acme.com>
> <http://acme.com> is whitelisted in _sad.quora..com
> <http://sad.quora.com> => "v=sad1 acme.com <http://acme.com>
<http://acme.com> -all"
> Mail will be accepted fornormal(_at_)example(_dot_)com
<mailto:normal(_at_)example(_dot_)com>
> <mailto:normal(_at_)example(_dot_)com
<mailto:normal(_at_)example(_dot_)com>> without any issues.
> Mail will be accepted forrestricted(_at_)example(_dot_)com
<mailto:restricted(_at_)example(_dot_)com>
> <mailto:restricted(_at_)example(_dot_)com
<mailto:restricted(_at_)example(_dot_)com>> only if
acme.com <http://acme.com> <http://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 "restricted(_at_)example(_dot_)com
<mailto:restricted(_at_)example(_dot_)com>
<mailto:restricted(_at_)example(_dot_)com
<mailto:restricted(_at_)example(_dot_)com>>"
> 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(_at_)example(_dot_)(_dot_)com <mailto:restricted(_at_)example(_dot_)com
<mailto:restricted(_at_)example(_dot_)com>>" 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. Inietf.org <http://ietf.org> <http://ietf.org>
mails, MAIL FROM
> address is "ietf-smtp-bounces(_at_)ietf(_dot_)org
<mailto:ietf-smtp-bounces(_at_)ietf(_dot_)org>
> <mailto:ietf-smtp-bounces(_at_)ietf(_dot_)org
<mailto:ietf-smtp-bounces(_at_)ietf(_dot_)org>>".
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 <http://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 domainietf.org <http://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 "valdis(_dot_)kletnieks(_at_)vt(_dot_)edu
<mailto:valdis(_dot_)kletnieks(_at_)vt(_dot_)edu>
> <mailto:valdis(_dot_)kletnieks(_at_)vt(_dot_)edu
<mailto:valdis(_dot_)kletnieks(_at_)vt(_dot_)edu>>" in
haveibeenpwned.com <http://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.
>
> 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 forietf.org <http://ietf.org> <http://ietf.org>. The isolated mail
address
> looks like ietf(_dot_)org(_at_)test123(_dot_)(_dot_)example(_dot_)com
<http://example.com>
> <mailto:ietf(_dot_)org(_at_)test123(_dot_)example(_dot_)com
<mailto:ietf(_dot_)org(_at_)test123(_dot_)example(_dot_)com>>
>
>ietf.org <http://ietf.org> <http://ietf.org> - The system allows
all mails from ietf.org <http://ietf.org>
> <http://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 “testkey123$twitter(_dot_)com(_at_)domboxmail(_dot_)com
<mailto:twitter(_dot_)com(_at_)domboxmail(_dot_)com>
> <mailto:twitter(_dot_)com(_at_)domboxmail(_dot_)com
<mailto:twitter(_dot_)com(_at_)domboxmail(_dot_)(_dot_)com>>”,
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
> <valdis(_dot_)kletnieks(_at_)vt(_dot_)edu
<mailto:valdis(_dot_)kletnieks(_at_)vt(_dot_)edu>
<mailto:valdis(_dot_)kletnieks(_at_)vt(_dot_)edu
<mailto:valdis(_dot_)kletnieks(_at_)vt(_dot_)edu>>>
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
> >ietf(_dot_)(_dot_)org(_at_)test123(_dot_)example(_dot_)com
<mailto:ietf(_dot_)(_dot_)org(_at_)test123(_dot_)example(_dot_)com>
> <mailto:ietf(_dot_)org(_at_)test123(_dot_)example(_dot_)com
<mailto:ietf(_dot_)org(_at_)test123(_dot_)example(_dot_)com>> 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.
>
--
Best Regards,
Viruthagiri Thirumavalavan
Dombox, Inc.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp
|
|