On Tue, 23 Apr 2019 22:30:45 -0600, pradeep(_at_)explodingmoon(_dot_)org said:
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.
Unfortunately, this draft is (in my opinion) fatally flawed, as the proposal
it's needed for some things that are easily doable without it, while being
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 pradeep(_at_)explodingmoon(_dot_)org and i give my location as
email service provider can provide me additional security by restricting
A registry isnt needed for this. The system at bluehost.com hopefully
*already* knows that you are pradeep(_at_)explodingmoon(_dot_)org and doesn't
check a registry. The mail servers at hotmail *already* know that you're
pradeepan88(_at_)hotmail(_dot_)com and doesn't have to check a registry.
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 pradeepan88(_at_)hotmail(_dot_)com mail to me". Permitting this
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
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
technologies that address these issues in a way that doesn't require a central
that constitutes a single point of failure.
In the last 5 years i have been frauded by emails like
efcc(_dot_)nigeria(_dot_)org(_at_)representative(_dot_)com 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
efcc(_dot_)nigeria(_dot_)org(_at_)representative(_dot_)com 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
Consider my email address. It says '@vt.edu'. 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.
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
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 'fred(_dot_)flintstone(_at_)vt(_dot_)edu' (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 'postmaster(_at_)vt(_dot_)edu' for email issues,
'registrar(_at_)vt(_dot_)edu' for all
things related to grades and transcripts, 'bursar(_at_)vt(_dot_)edu' for
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
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
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
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
or falsified information. Don't proceed on this front until you've read the
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
accurate enough for automated use is a hopeless task.
Its easy to use software to configure email delivery to multiple locations. I
am pradeep(_at_)explodingmoon(_dot_)org 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
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
so-called "dual use" technology. One of the ITAR requirements is that data has
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
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
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 tm(_at_)enough(_dot_)com who is in USA, i have to be able to
do a whois
of tm(_at_)enough(_dot_)com that says enough.com is in USA and avoid delivery
Why would your MTA even try to deliver to Spain if the MX entry is pointing to
And as mentioned multiple times in this note, the fact that 'enough.com' is
in the US is not a guarantee that their email provider is in the US as well..
enough.com is using a provider in Spain, insisting on only delivering to US
will guarantee that you can't send email to them.
Please don't bother submitting further IETF drafts until you have an
of how the current e-mail ecosystem actually works.
ietf-smtp mailing list