On Tue, 7 Dec 2004, David Woodhouse wrote:
On Tue, 2004-12-07 at 09:59 -0600, Daniel Taylor wrote:
(IP connect reverse lookup to forwarding host.example.org)
MAIL FROM: host.example.com
From: A(_at_)example(_dot_)net
I'd reject that MAIL FROM command; it's syntactically invalid and
doesn't even have a localpart. I'm going to assume your example was
supposed to be something like:
(connect from host.example.org)
HELO host.example.org
MAIL FROM:<A(_at_)example(_dot_)com>
From: A(_at_)example(_dot_)net
Yeah, that is what I was trying to write. I was a bit flustered.
Please refrain from insults, they never have a good effect.
I shall do the same.
OK, forged or not?
You can't tell.
Exactly my point.
If A(_at_)example(_dot_)com is using some method of end-to-end validation
you can get around this problem, but all methods of end-to-end
validation require both endpoints to be using them for effectiveness.
This is why we don't have end-to-end validation yet, even though
there are so many good options to choose from.
It could be a perfectly "valid" email really from A(_at_)example(_dot_)net
sent by the mail server at example.com and forwarded through
example.org.
Or, it could be all be made up except for the part about this
hop originating from forwarder.example.org.
I assume you mean from host.example.org. In which case you are entirely
correct.
Since there is no way to tell how careful forwarder.example.org
is about accepting mail for forwarding, there is no way to tell.
Right. And the situation is _exactly_ the same with SRS. It would be:
(connect from host.example.org)
HELO host.example.org
MAIL
FROM:<SRS0=xx=yy=example(_dot_)com=A(_at_)host(_dot_)example(_dot_)org>
From: A(_at_)example(_dot_)net
... and you _still_ can't tell. As you correctly state above, it could
all be made up except for the part about this hop originating from
host.example.org. (Well, you said 'forwarder.example.org' which didn't
appear anywhere in your example, but I'm trying to work around your
communication problems as well as I can).
Thank you for your indulgence here.
You have interpreted my muddy communication accurately.
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.
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.
THIS is why forgery-based forwarding is broken.
No. This is the reason why in _practice_ SPF doesn't actually achieve
anything more than CSV does.
CSV is somewhat of a latecomer here.
If CSV doesn't accomplish anything more than SPF does, why even
consider it?
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 even read from this part down.
Insults are non-productive in either direction,
sorry about contributing to them.
--
Daniel Taylor VP Operations Vocal Laboratories, Inc.
dtaylor(_at_)vocalabs(_dot_)com http://www.vocalabs.com/
(952)941-6580x203