On Sat, 2004-09-18 at 14:24 -0400, Meng Weng Wong wrote:
I plan to implement DomainKeys as soon as a plugin is
available for my MTA. Have you implemented it yet?
When banks start DomainKeys or S/MIME signing all outbound
mail, I promise to give up SPF and Sender ID.
The problem with DomainKeys is that it's not _ready_ yet. If my
understanding is correct, it still actually breaks in the real world --
mail sent via mailing lists which add a few lines to the mail will
appear to have a _broken_ signature. We need to make sure that is fixed
first.
As I said, it's massively counterproductive to sell something before
it's ready, especially if it's going to reject valid mail. All you'll do
is put people off and then they won't play when it really _does_ work.
But it's being worked on. Be patient :)
I agree that BATV/SES are the best solution to the
stop-bogus-bounces problem, better than SPF Classic because
they can be implemented unilaterally.
Right.
The cost is only slightly higher than SPF Classic: both require
domains to corral all their users into using the domain's
approved servers.
As Tony pointed out, that's not strictly necessary. I currently
implement SES on an opt-in basis. You can instantly stop getting any
bounces to mail you didn't send -- but you have to start using SMTP
AUTH. It's a per-user choice (actually per-address).
However, BATV/SES only limit the harm from the fraction of
the mail that does bounce. It does not address the fraction
of the mail that is delivered. SPF Classic and Sender ID do.
Actually SES _can_ address the fraction of the mail that is delivered.
Try delivering MAIL FROM:<dwmw2(_at_)infradead(_dot_)org> to any machine which
does
SMTP sender verification callouts, for example. I appreciate that
callouts are unpopular in some quarters -- the use of a stunt DNS server
and something like the SPF 'exists' mechanism has also been suggested,
as a way to assist recipients in identifying fake messages.
To reiterate my position: if you believe you have the One
True Solution, please go and help make it happen. If you
believe that someone else's One True Solution is wrong, it
is more productive in the long run to work on your solution
than attack somebody else's.
To a certain extent I agree with that sentiment, but not entirely. For a
start I don't like your choice of pronouns. We're all in this together;
there should be no 'us and them'.
If we sell them snake oil now, they're less likely to trust us later
when we _do_ get the formula right.
If I didn't think that SPF was actively harmful in the long run, I
wouldn't argue against it.
--
dwmw2