Please bear in mind that you are at the IETF, so if there are technical
objections to your proposal that mean that it doesn't solve the problem
that you are trying to solve, as is the case here, it doesn't matter how
many people want to do what you want to do—it shouldn't get consensus. In
other words, if you say "I have this problem, and here is what I propose to
do about it," and someone can clearly show that what you propose to do
about it won't work, then the IETF shouldn't be publishing a document
saying to do it that way.
On Tue, Jan 8, 2019 at 10:12 PM Viruthagiri Thirumavalavan
<giri(_at_)dombox(_dot_)org>
wrote:
So the snooper just makes a connection over port 26 to the server to fill
in the missing
information if they want it.
Ok I missed that one. Good point.
I'm not sure whether all snoopers would know all these loopholes.
You already mentioned "No" to this proposal. If anything else following
this thread, please let me know where you stand.
Thanks
On Wed, Jan 9, 2019 at 8:33 AM Mark Andrews <marka(_at_)isc(_dot_)org> wrote:
On 9 Jan 2019, at 1:59 pm, Viruthagiri Thirumavalavan
<giri(_at_)dombox(_dot_)org>
wrote:
The point is that when it's *that* easy to get the information
indirectly, you're
not providing actual security, you're providing security theater.
It's not *that* easy. And that's my whole point. There are ptr records
that points to in-addr.arpa rather than real domain.
But if you believe this proposal is pointless, then I'll take your vote
as "No" for this proposal.
So the snooper just makes a connection over port 26 to the server to fill
in the missing
information if they want it.
Thanks
On Wed, Jan 9, 2019 at 8:08 AM <valdis(_dot_)kletnieks(_at_)vt(_dot_)edu>
wrote:
On Wed, 09 Jan 2019 07:38:14 +0530, Viruthagiri Thirumavalavan said:
Not every PTR queries resolves to the correct domain.
74.125.129.26 => jm-in-f26.1e100.net (A google IP address, but point
to a
different domain owned by google)
I would be ok with indirectly someone getting the info rather than
directly
providing it.
The point is that when it's *that* easy to get the information
indirectly, you're
not providing actual security, you're providing security theater.
--
Best Regards,
Viruthagiri Thirumavalavan
Dombox, Inc.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)(_dot_)org <ietf-smtp(_at_)ietf(_dot_)org>
https://www.ietf.org/mailman/listinfo/ietf-smtp
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka(_at_)isc(_dot_)org
--
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