Subject: [ietf-smtp] Fwd: Request for comments Fwd: New Version Notification for draft-emailwhois-pradeepkumarxplorer-02.txt

From: [email-masked]
Date: Tue, 23 Apr 2019 22:30:45 -0600

----- Forwarded message from [email-masked] -----
    Date: Mon, 22 Apr 2019 23:56:11 -0600
    From: [email-masked]
Subject: Request for comments Fwd: New Version Notification for  
draft-emailwhois-pradeepkumarxplorer-02.txt
      To: [email-masked]
      Cc: [email-masked]

I still do not have a solution for my cybercrime as a customer to  
email and WWW.
I happened to be an Ex SUN employee and an engineer.

----- Forwarded message from [email-masked] -----
    Date: Mon, 22 Apr 2019 22:48:44 -0700
    From: [email-masked]
Subject: New Version Notification for  
draft-emailwhois-pradeepkumarxplorer-02.txt
      To: pradeep xplorer <[email-masked]>, Pradeep Kumar  
Xplorer <[email-masked]>

A new version of I-D, draft-emailwhois-pradeepkumarxplorer-02.txt
has been successfully submitted by Pradeep Kumar Xplorer and posted to the
IETF repository.

Name:		draft-emailwhois-pradeepkumarxplorer
Revision:	02
Title:		Extensions to WHois service to allow query on email identities
Document date:	2019-04-23
Group:		Individual Submission
Pages:		4
URL:             
https://www.ietf.org/internet-drafts/draft-emailwhois-pradeepkumarxplorer-02.txt
Status:          
https://datatracker.ietf.org/doc/draft-emailwhois-pradeepkumarxplorer/
Htmlized:        
https://tools.ietf.org/html/draft-emailwhois-pradeepkumarxplorer-02
Htmlized:        
https://datatracker.ietf.org/doc/html/draft-emailwhois-pradeepkumarxplorer
Diff:            
https://www.ietf.org/rfcdiff?url2=draft-emailwhois-pradeepkumarxplorer-02

Abstract:
     This document describes the need for a WHois email address service
     similar to the internet domainname WHois service. Theres a need for
     a registered email address as opposed to non-registered email address
     to fight internet SPAM, as well as encouraging email use for personal,
     commercial and legal and all kinds of purposes.An internet user
     can have multiple email identities.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

----- End forwarded message -----

----- End forwarded message -----

---

From: "Valdis Klētnieks" <[email-masked]>
Date: Wed, 24 Apr 2019 16:44:36 -0400

>      can have multiple email identities.

Unfortunately, this draft is (in my opinion) fatally flawed, as the proposal claims
it's needed for some things that are easily doable without it, while being unable
to provide workable solutions for others. At no place in the draft is a workable
solution proposed for an actual problem not already addressed via other means.

> A location field of the email address can be used to implement email security.
> if my email is [email-masked] and i give my location as Thailand, my
> email service provider can provide me additional security by restricting access
> from netherlands.

A registry isnt needed for this.  The system at bluehost.com hopefully
*already* knows that you are [email-masked] and doesn't have to
check a registry.  The mail servers at hotmail *already* know that you're
[email-masked] and doesn't have to check a registry. Similarly for
your yahoo.com and gmail.com identities.

If the proposal is that gmail.com be able to check a registry and accept mail
for your hotmail and explodingmoon.org mail, that's flawed and a non-starter,
as a mere registry doesn't provide the necessary functionality.  Currently,
mail is routed based on domain name, with no provision for special-casing based
on the left hand side of the address.  In other words, there's no way for gmail
to say 'send [email-masked] mail to me".  Permitting this requires
more than a registry - it requires a complete overhaul of SMTP, including all
the resulting scaling issues.

Currently, a mail server can know where to send mail for several billion
mailboxes just by caching the MX info for gmail.com, yahoo.com, hotmail.com,
and outlook.com, and one additional MX for each domain outsourced to those
companies.  Removing that would require that the server either cache or lookup
for each recipient, requiring a lot more local storage than just 4 MX entries.

> The current email protocols SMTP or whatever need to query sender email address
> only if its valid and authorised by the email regsitry, the senders email
> should be delivered.

Apparently the draft author has never heard of SPF, DKIM, or other already existing
technologies that address these issues in a way that doesn't require a central registry
that constitutes a single point of failure.

> In the last 5 years i have been frauded by emails like
> [email-masked] and they have extorted cash from me as if
> its legal fees to recieve funds and it has resulted in too much harm to me.

Side note:  A draft author admitting they're so unaware of internet security
that they fell for a 419 scam is a good way to lower the chances of the draft
getting taken seriously.  They probably need to totally re-write this section.

It's also probably a sign that they need to learn a lot more about the Internet
before writing IETF drafts. See also the above comments regarding SPF and DKIM.

> If i can configure my email client to recieve emails from those authorised by
> email registry, i would not have this problem.

Actually, you still would.  Because if you can register your email address, the
scammers can register theirs. And if your mail agent told you that the address
[email-masked] was registered, you'd probably still fall
for the scam.

> VerifyEvnevlope that takes as input an email header and reports if the sender
> of the email is really who the header claims to be.

See above regarding DKIM and SPF.  Also, the statement "really who the header
claims to be" indicates a vast lack of understanding of the concept of "identity".

Consider my email address.  It says [email-masked]'.  However, I now no longer have
any affiliation with Virginia Tech other than 'Retiree' - the university
recognizes that those retiring may have been using the same address for a long
time (this one dates to June 1993) and changing it can be disruptive, and
provides continuing e-mail services as a retirement benefit.

Careful reading of the headers of this message will however reveal that it went
first through Gmail, and thence to a Virginia Tech server (due to VT's
outsourcing to Google Apps).  By the time it leaves Virginia Tech's servers,
it's already been established that the From: is valid (as VT doesn't do open
relay of mail).  So an external registry of all valid VT addresses isn't needed
in order for a remote server to verify it's a valid From: - all that's needed is
verifying that the mail came from an authorized VT server.

Hello, SPF.

But let's dig a bit deeper into this "identity" thing.  The mere fact that the
mail comes from an existing address doesn't actually *tell* you as much as you
think it does. In particular, there's two related issues:  Authentication and
Authorization.

First, Authentication: 

The fact an email address exists doesn't actually tie it to a specific person.
In fact, it could be an alias - and in my case, it *is* an alias address tied
to the actual userid used for authentication by the Gmail and VT mail systems.
I could as easily create an alias [email-masked]' (a famous TV cartoon
character here in the US) - and it would tell you zero about my true identity.

And in fact, there are very real uses for such pseudonym accounts.  VT has
special handling policies in place for certain high-security accounts. Examples
include students who are children of foreign diplomats or the extremely rich
and thus terrorism/kidnapping targets, or victims of domestic violence or
stalkers.   In some parts of the world, political activists are unable to use
their real names without risking their lives.

And then there's another can of worms - role identities.  These include
things like [email-masked]' for email issues, [email-masked]' for all
things related to grades and transcripts, [email-masked]' for financial issues.
None of these are a specific person - they're all teams of 5 to 20 people who
collectively work as a unit.  There also exist totally automated role identities,
such as the From: address that was used by our system monitoring software
to report system issues detected by automated software.

Clouding the issue further:  How do you identify that this mail actually came
from me? My e-mail credentials could have been compromised and used to send
spam.  My cat may have walked on the keyboard and managed to trigger a 'send'
of an incomplete draft in progress (surprisingly, this has only happened to me
twice in almost 4 decades of computing while living with cats).

Systems like PGP help, except you need infrastructure to ensure that the key
belongs to the person/entity it claims to belong to.  And a digital signature
doesn't actually prove the person signed it - it proves that a computing
process had access to both the private key and the signed data (a subtle but
very important distinction).

Authorization:  Note that none of the above addresses the question of what
credence you should give an e-mail even if you've identified the source.  OK,
that e-mail that received did come from an authenticated and registered user.

But does that mean it's a good idea to send them money to collect your lottery
winnings?

> WHoisEmail This takes the email and shows information that can be used to
> identify the sender. This can be protected by the senders password or public
> key. The information retrieved can be the location, identiy documents,
> credentials, certificates, finger prints etc.

Wow.  A central registry.  One-stop shopping for identity theives, despotic
governments, and a single point of failure for denial-of-service attacks. What
Could Possibly Go Wrong?

Also, see the above discussion about role identities. What identification information
do you store for them?

Additionally, an explainion is needed on how the purported identity information
is gathered and verified by this registry, to prevent the upload of a stolen identity
or falsified information.  Don't proceed on this front until you've read the repeated
threads on the NANOG mailing list regarding bad WHOIS data for domains and
failures of geolocation databases.  It's not as easy as you think.

The current domain WHOIS data is *nowhere* near accurate enough to use
as an automated data source for production systems. Trying to expand from
a system that has enough trouble with 150 million or so domain names that aren't
accurate enough for automated use to one with billions of entries that have to be
accurate enough for automated use is a hopeless task. 

> Its easy to use software to configure email delivery to multiple locations. I
> am [email-masked] now in palakkad internet can be configured so an
> emails that originates from usa delivered inside USA only.

This has several possible meanings, all of which indicate a confusion about how
the Internet works.

If it means you can configure explodingmoon.org to not accept mail from inside
the US, that does *NOT* mean that it's delivered inside the USA only - other
sites in Germany or Japan can still accept it.  You have *zero* control over
where a remote mail source can send, other than your own receiving site.

If you mean that you can configure your own mail server such that if you're
visiting the US, you can only send to other US sites, that means you can't send
your family and friends in India (where I assume you are based) mail about the
visit.

And "originates from" and "delivered inside" are fuzzy concepts as well. I've
had an actual case where an IBM systems engineer based in Austin, Texas
downloaded an email from me to his device while he was at Los Angeles
International Airport, composed a reply and hit send while somewhere over the
Pacific Ocean. When he lands in Tokyo, his device auto-connects to the airport
wifi and fires up a VPN to IBM Tokyo's office to upload the mail, which leaves
an IBM server (not sure if it was Tokyo or Austin Texas, or somewhere in IBM's
cloud). It then bounces back and forth between GMail servers somewhere on the
west coast of the US and VT's mail servers on the east coast. Finally, it sits
on a GMail server (possibly on the west coast of the US, but see below) until I
run IMAP to download and read it at my aunt's apartment in Riga, Latvia. (I
specificaly remember looking at this mail in particular because I knew we were
both travelling and I had not expected a reply for 2-3 days. The engineer filled
me in on the VPN part...).

Adding to the fun - the Received: headers said that the mail was accepted into
GMail's backend mailstore on a server with a US Pacific time zone.  However,
GMail is *known* to track where a user is and pre-stage their inbox contents to
a server farm nearer to the user.  So  when I fire up IMAP, my email could
already have been in Ireland or Germany and I was transparently routed there
via a geographic-sensitive reply to the DNS query for 'imap.gmail.com'.

(This auto-migrate was an issue for us when I was at VT - we had users who were
doing US government funded research covered by a set of export controls known
as ITAR (International Traffic in Arms Regulations) because the research was into
so-called "dual use" technology. One of the ITAR requirements is that data has to
remain on servers physically located on US soil.  And Google was unwilling to
negotiate that requirement into our outsourcing contract in a way acceptable to VT).

So. Where did the IBM engineer's mail "originate"?  Above the Pacific? Tokyo
International? IBM Tokyo? IBM Austin? IBM Cloud? Where was it "delivered"?  VT
servers? GMail servers? IF GMail, which country? Or was it my laptop in Riga?

> sofwtare like DNS tables and routing can be changed to have delivery to a
> duplicate place.

Delivery to an alternate place on a per-domain level is easy - that's what MX
records are for.  To a duplicate place, almost impossible unless the original
destination address is an exploder/forwarder (which comes with its own
challenges in a world with SPF and DKIM).

> This has to be avoided by a central registry or some other techniques.

What exactly has to be avoided, and why?

> If i am emailing [email-masked] who is in USA, i have to be able to do a whois
> of [email-masked] that says enough.com is in USA and avoid delivery to spain

Why would your MTA even try to deliver to Spain if the MX entry is pointing to the US?

And as mentioned multiple times in this note, the fact that 'enough.com' is based
in the US is not a guarantee that  their email provider is in the US as well.. So if
enough.com is using a provider in Spain, insisting on only delivering to US servers
will guarantee that you can't send email to them.

Please don't bother submitting further IETF drafts until you have an understanding
of how the current e-mail ecosystem actually works.