Re: [Uta] SMTP Over TLS on Port 26 - Implicit TLS Proposal

[Viruthagiri Thirumavalavan <[e-mail]>]

@Vittorio Bertola

I'm trying to help the IETF community in the way I can. Of course I'm gonna
revise my work and ask for feedback. That's what this mailing list is for
right? If the mailing list terms says that I should not ask feedback upon
improving my work, then yes what I'm doing is wrong.

You didn't put any effort to help me, yet you think you have the right to
attack me on a public forum? Do you really think I'm spending my time here
for my personal gain?

It seems like your intention here is to attack me based on my few months
old post. You also seem quite confident that I lied there without even
going through my paper. If you had completed my paper, then you wouldn't be
so cocky here.

Ok you won. I'm gonna leave this mailing list because you feel annoyed here
because of me.

My only question here is, how confident are you that my spam solution never
gonna work? e.g. I would give you a million dollar if it works, I would
kill myself if it works etc.

You also seem like a honourable man. So I believe you would honour your
words if my spam solution really work.

Before you give your word, you should know this is what investors think
about my work.
https://www.dropbox.com/s/599s5iz25h1d680/Screenshot%202019-01-07%2017.12.11.png?dl=0

And that's coming from an engineer turned investor who have experience in
mail servers. So I'm not trying to rip off innocent investors. That
investor turned me down because my solution requires bigger bets. So yeah
just because I don't have a billion dollar company in few months doesn't
mean my solution failed. It means I'm still trying to find an investor who
is ready to go through my 300 pages research paper.

You might have had some respect for me and my work, if you really had gone
through the presentation I posted on that day. I really hate guys like you.
Because guys like you act like "know-it-all" and the guys like me are the
victims.

@Alice Wonder

You are really a nice person and it's really an honour to have discussion
with people like you.

I was actually working on my product. When you are working with SMTP, you
definitely know the SMTP problems. I noticed the STARTTLS downgrade issue
not addressed properly. And I felt both STS and DANE are overkill for an
average user. So I signed up to this mailing list and posted my proposal. I
have other proposals too for SMTP. But I don't think guys like Vittorio
gonna appreciate my work until I gain some public reputation. To their eyes
I'm a overconfident idiot.

So I'll leave this mailing list for now. But I love to have a discussion
with people like you. So I'll collaborate with you someday.

@Everyone

Thanks for helping me. It means a lot. Good luck


On Mon, Jan 7, 2019 at 4:20 PM Alice Wonder <[e-mail]> wrote:

> On 1/7/19 2:09 AM, Viruthagiri Thirumavalavan wrote:
> > Alice thanks for the insight.
> >
> >     Rather than use a hostname to specify SMTPS only, how about a DNS TXT
> >     record to indicate SMTPS only?
> >
> >
> > Third party mail hosting services usually provide services for millions
> > of domains. You are asking those millions of people to go for 1 more
> > step. I'm asking that step should be embedded in the mx hostname. Users
> > should do the steps as they did before, but now the mx records contains
> > smtps prefix.
> >
>
> They already will query for the existence of the MTA-STS record, and
> likely have unbound or similar caching resolver running on the localhost
> or at least at same hosting facility that caches the response to the query.
>
> Why not just require STARTTLS if the TXT record for
> _mta-sts.example.org. exists? They check for that anyway.
>
> >     And if that DNS TXT record exists, rather than waste a < 1024 port
> >     number, just have the MTA client use Port 25 with STARTTLS required.
> >     Then it is just like MTA-STS except w/o the HTTPS component that
> >     secures
> >     the MX record.
> >     But bottom line is to be RFC compliant, an MX host MUST accept on
> Port
> >     25 without encryption.
> >
> >
> > You are worried about wasting a port. But I'm worried about bringing
> > full possible encryption to the SMTP.  I have never heard of many of the
> > services found in < 1024 ports. You maybe too. So i'm pretty sure IANA
> > ok with assigning a new port to SMTPS.
>
> I do want full possible encryption brought to SMTP. This is why I
> encourage DANE for SMTP with MTA-STS as a backup for servers / clients
> that do not implement DANE for SMTP.
>
> The problem is solved.
>
> >
> > My proposal is to being "Implicit TLS" to the SMTP relay. If you don't
> > allocate a new port, then people are not going to take the solution
> > seriously. And as you mentioned, an MX host MUST accept on port 25
> > without encryption. So you can do all the hack you want like STARTTLS,
> > port 25 is never gonna be treated as a fully secure protocol. Via
> > STARTTLS we are trying to provide "best effort" security. SMTPS can
> > provide "Full effort" security. That's the maximum possible security we
> > can provide. Top to bottom everything encrypted. We all moved to HTTPS
> > today.  It will take many decades to completely move to SMTPS. Maybe 20
> > years. But if we worry about wasting a port today, then it's gonna take
> > forever.
>
> You are missing the point.
>
> It is up to MTA client to decide whether or not encryption should be
> required. You can have your MTA client do that today, right now, without
> needing to use a different port.
>
> What you want is a client that gets its cue to go into that secure only
> mode from the MX record, but that is an easily defeated trigger if the
> MX record is not secured.
>
> There are two ways to secure the MX record - DNSSEC and MTA-STS, both of
> which then already require STARTTLS without needing a new port assigned.
>
> There is also the STARTTLS Everywhere project which provides a GPG
> signed json file of hosts you should require STARTTLS with. It is fairly
> easy to turn that JSON fine into a Postfix policy map, I assume the same
> applies to other MTA clients. That is a good temporary solution while
> software/admins catch up with implementing DANE and MTA-STS in the MTA
> clients and servers. And it does not require a new port.
>
> Port 26 gives us nothing that a policy map file with domains we know
> should require STARTTLS does not also give us.
>
> How about instead of designating a new port, a "best practices" RFC is
> created suggesting that MTA clients require STARTTLS when the the
> MTA-STS record exists, whether or not the policy file can be
> successfully retrieved by HTTPS?
>
> That will allow system administrators who are having trouble setting a
> web server for the MTA-STS policy file to still advertise they have set
> up TLS on their mail server.
>
> How about this:
>
> When the MTA-STS DNS record has a serial number of 0 *and*
> mta-sts.example.org domain name does not have an A or AAAA record, then
> the MTA client SHOULD still require STARTTLS.
>
> That would allow MTA clients to know they should at a minimum require
> STARTTLS with mail sent to that domain, it would not require any DNS
> queries beyond what is already required, and it would not require DNSSEC
> or a HTTPS web server.
>
> But MX admins should still do both DANE and MTA-STS whenever possible to
> secure the MX record.
>
> _______________________________________________
> Uta mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/uta
>


-- 
Best Regards,

Viruthagiri Thirumavalavan
Dombox, Inc.