ietf-smtp
[Top] [All Lists]

Re: SMTP and Kerberos

2011-11-03 21:28:29

On 11/3/11 4:54 PM, Hector Santos wrote:
Douglas Otis wrote:
John,

I would like to thank you, Russ, and Keith for the feedback.
Hilarious. Are you intentionally trying to be ignorant? I guess you are.
Hector,

Not at all. I agree with most of the issues that John raised. I also do not believe in pixie dust, secret sauce, or other forms of magic being helpful either. Domain protection is intended for MTA to MTA exchanges. Use of user/password in base64 is unworkable on a global scale. It is a complex problem having many possible configurations. The challenge is to find solutions causing the fewest changes that still retains the general goals represented by Kerberos constructs.
The goal is to ensure the domain name used by an entity can remain a solid basis for acceptance.
The way I see it, practically speaking, Ipv6 will bring back the old simple solution of using "Allow IP Relay Tables" and the "Roaming user" issue would be a thing of the past.
http://bgp.potaroo.net/v6/as6447/

Please notice currently there are 228,848 billion announced IPv6 /64 equivalent prefixes. A size 65k larger than the entire IPv4 unicast space. Also note this space is growing exponentially, where the chart has become vertical. Have fun keeping up with that.

At the smaller /48 prefixes, 538, 474, 403, 271, and 270 million announcements are in Germany, Japan, rest of EU, Australia, and Korea respectively. Even so, all /48s represent just .000067% of the entire announced space.
You can ignore that feedback too.
I would never do that. Also don't depend upon tools to categorize sources based upon rDNS crawls. Neither of us will live long enough to make a dent at this mapping. What clues will you use? What games can be played with that strategy? There is little within email that is trustworthy.

When one looks at the number of domains used for legitimate email, the numbers become dramatically more manageable. The challenge is to find a robust method to identify domain sources where the burden has been shifted toward the sender. After all, domain protection largely benefits senders.

The requirement to retain invalid DKIM signatures, and lack of requirements for specific relationships makes dependence on DKIM this highly prone. If you are not planning on accepting IPv6 connections, also expect a growing portion of inbound traffic carried through Large Scale NATs. Good luck at figuring out where that traffic originated. :^(

Placing your inbound servers into a "protected realm" says you wish to establish a robust method for accepting messages from legitimate domains that you'll take steps to protect.

-Doug

<Prev in Thread] Current Thread [Next in Thread>