Erik de Castro Lopo <[EMAIL PROTECTED]> writes:
> I am in the process of setting up mail for a new domain and I'm
> interested in people's opinions on these two:
>
> http://en.wikipedia.org/wiki/Sender_policy_framework
> http://en.wikipedia.org/wiki/DomainKeys
This is sadly likely to be contentious, because opinions on the first
vary wildly. I am firmly in the anti-SPF camp, and think DomainKeys
reasonable but not -- right now -- wildly effective.
> I have already added an SPF text DNS record for the domain as well as
> installed and set up the postfix-policyd-spf-python package (I'm using
> Postfix for the MTA).
>
> During testing I realised that SPF or at least this implementation I
> am using has a serious flaw that will result in mail that should be
> blocked by SPF actually getting through.
If you don't mind, what implementation flaw? While I mislike the tool
it always helps when someone calls up because their mail is broken...
So, SPF: I don't like it. Their original design completely ignored a
whole bunch of the standard SMTP architecture and practice, in that the
processing of .forward style email redirection was ignored.
The SRS, or Sender Rewriting Scheme, only requires that all SMTP servers
on the Internet are redeployed to implement a new protocol similar to,
but not exactly like, SMTP.
They also authenticate the wrong thing: the path your email went
through, which SMTP is *explicitly* designed to treat as
insignificant,[1] is treated as the most important attribute in
authenticating the origin of the message.
This means that any change in message routing, or any scenario where the
SMTP outbound path changes, requires updating your description of
"permitted" systems.
That imposes, at minimum, a maintenance overhead on anyone working on
your network, and also significantly increases the risk that you can't
verify authenticity correctly after the current moment.[2]
Anyway, to address the second item on your list:
> I then looked at Domain Keys the wikipedia entry has a large section
> titled "Weaknesses".
This section is a good thing; their analysis is reasonable and accurate
to the best of my knowledge. They seem to have a good summary of the
risks and costs of the system.
Was there something specific that concerned you in the discussion, or
just that there were admitted weaknesses to the protocol?
As far as it goes I don't think DomainKeys is a bad design: it is
compatible with SMTP as it stands, it can be incrementally deployed
without any problems.
It also authenticates the right thing: that the *sending server* is
authorized, not that the path the email followed is authorized.
> Has anyone else implemented these? Are they worthwhile? Problems?
I have a reasonable amount of unpleasant experience with SPF, and
generally find it worthwhile. In my experience most deployments of SPF
are broken one way or another.
Often they are deployed incorrectly by people who don't fully understand
their deployment, or end up screwed because they need to include a bunch
of SMTP servers operated by third parties who, for whatever reason, are
not cooperative.
Oh, and many businesses come to trouble because they roll out SPF,
advertise their forwarders, then have (senior) staff go off and get a 3G
modem, broadband, or whatever, and send email that gets blocked because
it comes from an illegitimate server.
Problems here would be more widespread, in my experience, if more places
implemented *both* parts of SPF -- it seems to be very popular to
publish SPF records for your mail, but to ignore them completely on
inbound email.
However, keep in mind that most of my dealing will have been with broken
SPF records, or when senior staff have their email blocked because they
bought a 3G modem. I am probably seeing more of the bad and less of the
good side[3] of SPF.
Regards,
Daniel
Footnotes:
[1] The SMTP MX system replaced the "bang path" style solution that was
an explicit hop-by-hop email routing protocol, for reliability and
flexibility, quite some time back now.
[2] Domain Keys suffers this, also, in that a changed key will
potentially cause material signed with an older key to become
invalid. This is a much less common change than adding or removing
an outbound MX, in my experience and opinion.
[3] I presume that SPF must actually achieve something, for someone,
other than making them feel good about fighting spam. I just have
not actually seen any evidence yet.
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
