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

[Viruthagiri Thirumavalavan <[e-mail]>]

>
> 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).


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=
[e-mail]> wrote:

> 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 <[e-mail]
> > <mailto:[e-mail]>> 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:<[e-mail] <mailto:[e-mail]>
> >     <mailto:[e-mail] <mailto:[e-mail]>>>
> >     > 250 OK
> >     > RCPT TO:<[e-mail] <mailto:
> [e-mail]>
> >     > <mailto:[e-mail] <mailto:
> [e-mail]>>>
> >     > 250 OK
> >     > RCPT TO:<[e-mail] <mailto:[e-mail]>
> >     <mailto:[e-mail] <mailto:[e-mail]>>>
> >     > 250 OK
> >     > RCPT TO:<[e-mail] <mailto:[e-mail]>
> >     <mailto:[e-mail] <mailto:[e-mail]>>>
> >     > 250 OK
> >     >
> >     > Mail will be accepted [e-mail] <mailto:
> [e-mail]>
> >     > <mailto:[e-mail]
> >     <mailto:[e-mail]>> 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 [e-mail] <mailto:
> [e-mail]>
> >     > <mailto:[e-mail] <mailto:[e-mail]>> without
> any issues.
> >     > Mail will be accepted [e-mail] <mailto:
> [e-mail]>
> >     > <mailto:[e-mail] <mailto:[e-mail]>>
> 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 "[e-mail] <mailto:
> [e-mail]>
> >     <mailto:[e-mail] <mailto:[e-mail]>>"
> >     > 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:[e-mail] <mailto:
> [e-mail]>>" 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 "[e-mail] <mailto:
> [e-mail]>
> >     > <mailto:[e-mail] <mailto:
> [e-mail]>>".
> >     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 "[e-mail]
> <mailto:[e-mail]>
> >     > <mailto:[e-mail] <mailto:[e-mail]>>"
> 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.org@test123..example.com <http://example.com>
> >     > <mailto:[e-mail] <mailto:
> [e-mail]>>
> >     >
> >     >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$[e-mail]
> <mailto:[e-mail]>
> >     >     <mailto:[e-mail] <mailto:
> twitter.com@domboxmail..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
> >     > <[e-mail] <mailto:[e-mail]>
> >     <mailto:[e-mail] <mailto:[e-mail]>>>
> >     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
> >     >     >[e-mail] <mailto:
> [e-mail]>
> >     >     <mailto:[e-mail]
> >     <mailto:[e-mail]>> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ietf-smtp
> >
>
>
>
> _______________________________________________
> ietf-smtp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf-smtp
>


-- 
Best Regards,

Viruthagiri Thirumavalavan
Dombox, Inc.