ietf-mxcomp
[Top] [All Lists]

RE: DEPLOY: Over-running TXT dataspace in FQDN (-protocol I believe)

2004-08-27 11:27:11

On Fri, 27 Aug 2004, John Glube wrote:

I should have been clearer. Web hosting services offer sub
domains. However, there is a threshold cost involved, which
can sometimes be an incremental amount on a monthly basis.

We're arguing about a theoretical incremental cost for someone to publish
a subdomain record through their ISP?  If that ISP provides email service
they are going to figure out they have to just do this for their
customers, in a sub-domain or not in a sub-domain, otherwise those
customers are going to another ISP that does.  The incremental cost of
publishing a record in a sub-domain is inconsequential when compared with
publishing a new data record and re-tooling the SMTP infrastructure to
determine where mail should actually be coming from.

Perhaps it is my innate sense of irony. Here we are, 4 days
into last call, when someone like yourself comes in from
the field and says hey guys "she just don't fit." :-)

I brought up the point at IETF when the proposal to split was made, then
shopped it around with a few of our major customers over the past couple
of weeks, and here I am with more details.

Whether the financial institutions' design criteria, which
I gather from your comments has stamped the creation of
certain key aspects of Sender-ID is the right approach to
dealing with the phishing problem?

Yes, they feel that Sender ID is a useful band-aid for the immediate
problems, and recognize the need to develop a more robust solution (ie
cryptographic).

*Any* IP based authentication solution is going to have limitations,
primarily that they can only authenticate the most recent hop that a
message takes.  For these large customers I'm talking to, a large portion
(usually more than 50%) of their emails go precisely one hop from the
sender relay to one of either AOL, Yahoo, or Hotmail.  And unknown but
expectedly large portion of the other mails go one hop as well, but its
impossible to tell how many others may be forwarded.

So, for a large portion of the customers these senders are trying to send
authenticated emails to, Sender ID will help.  There is going to be
friction in getting mid-points for forwarding solutions upgraded to add
Resent-From and Resent-Sender headers, but those changes are much less
invasive than SRS rewriting.  Who knows, we may skip the whole
upgrade-the-middle-part and move straight to deployment of end-to-end
crypto auth, Sendmail is working hard on that as well.

But in the short term, Sender ID offers as many good benefits as any
IP-based message authentication scheme can.

-Rand


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