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>
|
- Re: SMTP Kerberos Considerations, (continued)
- Re: SMTP Kerberos Considerations, Robert A. Rosenberg
- Re: SMTP Kerberos Considerations, Hector Santos
- Re: SMTP Kerberos Considerations, Robert A. Rosenberg
- SMTP and Kerberos (was: Re: smtp-traffic-control), John C Klensin
- Re: SMTP and Kerberos, Douglas Otis
- Re: SMTP and Kerberos, Hector Santos
- Re: SMTP and Kerberos,
Douglas Otis <=
- Re: SMTP and Kerberos, Hector Santos
- Re: SMTP and Kerberos, Douglas Otis
- Re: SMTP and Kerberos, Douglas Otis
- Re: SMTP and Kerberos, Russ Allbery
Re: draft-atkins-smtp-traffic-control, Douglas Otis
Re: draft-atkins-smtp-traffic-control, Alessandro Vesely
|
|
|