spf-discuss
[Top] [All Lists]

Re: SPF and Responsibility

2004-07-22 08:20:40
Michel Bouissou wrote:
Le jeudi 22 Juillet 2004 16:23, Daniel Taylor a écrit :

[...] Times change, and now the problems
of the distributed system outweigh the benefits and we need to go
to a more controlled system like the web.


As another folk said, let's before that try to get email servers admins to first implement and use the simple methods that just are "a well configured server and network".

As I stated in a parallel message, most e-mail could reasonably
arrive from a server where "MAIL FROM", HELO, and From: all match
with a valid MX that has good A and PTR records. This would make
smtp source authentication as easy as http source authentication.

The "legitimate" SMTP servers that don't even have any reverse DNS are countless. Many (professional) servers from many companies currently HELO with a name that isn't even an FQDN, or doesn't resolve to anything, or resolves to an IP address that differs from their actual IP address.

Many automated email (which one may need to receive) come with a Return-Path pointing to a non-existing address, and sometimes even to an undefined subdomain or host.

My receiving MTA rejects all email that comes from such ill-configured servers, but I have an ever-growing "whitelist" of "accept mail from this broken server or sender", because there are mails from such servers that I, or any other user from my domain _need_ to get.

There is a definite power relationship going here.
BigCompany can get away with misconfigured servers because of
it, you or I cannot.

And even though I spent hours writing to postmasters of these domains, they simply don't give a shit and won't go and fix it -- postmaster's mail for them must be forwarded to /dev/null, when it doesn't bounce with "Unknown recipient". Yes, rfc-ignorant.org is here for that.

In a corporate environment, go tell a non-IT manager that you are and will be rejecting the email about the big contract from big-customer.com just because of "some obscure technical misconfiguration issue somewhere" that the manager doesn't care or want to hear about. He just wants to get the damned mail from big-customer.com no matter big-customer.com's servers can be ill-configured. And you will actually be fired if you keep on filtering the big contract email for Mr Big-Manager...

On the flip side, as an IT guy try explaining to Mr. Big Manager why
his e-mail to major_contract(_at_)aol(_dot_)com is bouncing because you
don't have a valid mail server configuration.

So before SPF or any other authentication scheme gets _very_ widely used, with accurate published records for every domain, and correctly configured MTAs, I believe we still have a looooong road.



But you _should_ be able to have an expectation of authenticity
under certain circumstances.


Then what you need is digital signature, S/MIME, PGP or whatever. These solutions have been around for a decade, implemented in the most widely used MUAs, and what percentage of users do actually use them ?

There are degrees of authentication and protection.
In snail mail you have:
Postcards.
Regular mail on plain paper.
Mail with letterhead stationery.
Registered mail.

In e-mail you have:
Completely unauthenticated e-mail.
DNS valid source e-mail (MX or SPF match).
Cryptographicly signed e-mail.
Encrypted e-mail.

All of these levels are useful.
Frankly, most people don't use crypto because it is
to difficult to configure and maintain.

--
Daniel Taylor          VP Operations            Vocal Laboratories, Inc.
dtaylor(_at_)vocalabs(_dot_)com   http://www.vocalabs.com/        
(952)941-6580x203


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