David Woodhouse wrote:
On Tue, 2004-12-07 at 11:41 -0600, Daniel Taylor wrote:
In the process you have also pointed out why SRS, RSR, and pretty much
every other header-based attempt at fixing the "forwarding problem"
is broken. Bringing back the bang-path just won't work when there
are people out there determined to undermine the system.
Right. You can't use a hop-by-hop solution and _pretend_ it gives you
true end-to-end authentication. You need to actually use a scheme which
was designed to work end-to-end in transit through the mail system. A
scheme based on IP addresses is not sufficient.
Not sufficient, but necessary.
The IP address is at this point the necessary starting
point for all sender authentication because it is the hardest
thing to spoof.
The only really effective way I can see to deal with this is for
each forwarding step to take responsibility for and keep track of
forwarded messages so that the path can be cascaded back in the
event of a failure. This is unspoofable, and would reduce the amount
of traffic from bogus bounces.
That's basically what SRS attempts to do, surely? I'm not sure what you
envisage in the above paragraph which is materially different from SRS?
What I envisage would omit the forwarding part of SRS (the bang-path
redux).
Setup:
A(_at_)a->B(_at_)b->C(_at_)c
First step:
HELO host.a
MAIL FROM: A(_at_)a
From: A(_at_)a
To: B(_at_)b
To be forwarded, generate TAG, remember that TAG-B(_at_)b
points back to A(_at_)a from C(_at_)c for timeout period (5 days).
Second step:
HELO host.b
MAIL FROM: TAG-B(_at_)b
Recipients: C(_at_)c
From: A(_at_)a
To: B(_at_)b
Now if host "c" refuses delivery it rolls back.
This looks very similar to SRS, except that TAG is local to "b", my
proposed method would not attempt to shortcut the process at all, and
would not include reverse route information in the headers.
Arbitrary messages from arbitrary hosts are ignored since TAG is
associated with a particular source-destination pair only
known to the forwarding host.
TAG should be an occasionally reseeded pseudo-random number in some
large base (hex, base-36, or base-62 come to mind as likely).
I thought I had seen/posted this before, but I guess I was mistaken.
CSV is somewhat of a latecomer here.
If CSV doesn't accomplish anything more than SPF does, why even
consider it?
Because it achieves as much as SPF does, but without the quixotic
attempt to change common forwarding practice.
If there are two solutions which offer the same benefits, but one is
compatible with existing practice and the other is not -- is it really
so hard to choose between them?
Except CSV doesn't authenticate MAIL FROM, and many providers
already reject if HELO doesn't map to the source IP. This
is a fairly standard Sendmail config, and I would suppose
that the other major MTA's support it directly as well.
So I fail to see what CSV gains the well configured domain.
Please note, however, that the vast majority of e-mail traffic
is point-to-point (including in all cases the first hop of forwarded
messages). Solving the point-to-point forgery problem does go a long
way toward solving the general forgery problem.
Not really, for the same reason as having a whitelist doesn't go a long
way to giving you a blacklist. SPF allows you to determine which mail is
definitely _valid_. But it doesn't allow you to determine which mail is
definitely _invalid_. And it's the latter which is useful.
Positive validation of whitelisted domains takes the validated mails out
of the potential pool of false positives. This allows spam filtering
software to be stricter in examining the remaining messages.
Positive validation of blacklisted domains saves the trouble of further
filtering and reduces false negatives.
--
Daniel Taylor VP Operations Vocal Laboratories, Inc.
dtaylor(_at_)vocalabs(_dot_)com http://www.vocalabs.com/
(952)941-6580x203