nwp at nz
Oct 9, 2003, 2:23 AM
Post #4 of 6
(338 views)
Permalink
|
On Tue, Oct 07, 2003 at 12:23:47PM -0700, Ted Cabeen wrote:
> Meng Weng Wong <mengwong [at] dumbo> writes:
> > Solution 2: per-recipient custom whitelisting.
I think that rather than just trying to come up with "something that might
work", it is a good idea to consider what is happening at a slightly more
abstract level (and so ensuring that we have a model that is consistent).
I don't want to see this turning into an ugly great hack.
So...
When a mail is forwarded, what is happening? Is the forwarded mail from the
original sender? Is it a new mail from the forwarder which happens to be
pretty much identical to the original? Is it always the same, or does it
vary?
It seems to me that there are three distinct possible situations -- where
the relay or forward is imposed by the originator, where it is imposed by
the recipient, and (most awkwardly) where it is imposed by a third party
(e.g. there is no direct connectivity between sender and recipient and a
gateway must be used).
If the originator is responsible for the relay then they should also be
responsible for ensuring that the sender data is valid when it leaves the
relay. Example: I send mail from home via a dialup to random_isp, and
the mail is relayed by my smarthost at work. In this situation I must ensure
that either the smarthost is listed in SPF as an emitter for my personal
domain, or that the smarthost rewrites the envelope sender to be from another
domain for which it is listed.
If the recipient is responsible for the relay then they should also be
responsible for ensuring the safe delivery from the point where the relay
receives it (and verifies the SPF). Example: I have a .debian.org address
which forwards to my personal address. I must either rewrite the sender so
that my MX will accept it (perhaps I have no control over the MX), or I
must configure the MX to trust debian's servers to send on some category
of mail.
The third situation is the most awkward.
Once upon a time it was common for messages to be relayed by random third
parties -- to mail from JANET to the NSFNet I would have had to mail
to "someone%nsf.net.address [at] uk". In that situation, it would
be impossible for the final receiving server to verify that the sender was
who they claimed to be, unless nsfnet-relay gave them some indication that
it was sure who the sender was, and they also trusted nsfnet-relay.
Pretty awkward. And pretty much the same situation we have now, although now
it is less common.
If you are sure that the relay knows and is honest about the original sender,
then you can trust all sender data that that relay sends. This may be
possible, but there may be an awful lot of relays out there that you don't
yet know about. If it turns out not to be possible, then you require some
form of communication with the originating server, some of which will have
to be outside the message in question.
We have to add some kind of authentication information to the message itself,
which can be verified against some information we got from somewhere else.
The simplest example of this would be to GPG-sign the message individually, but
there are all sorts of possibilities involving the emitting server (listed
in SPF as a valid sender for the alleged sender domain) either using a
shared secret or some form of PKI to sign the message. So the shared secret
or public keys would have to be distributed somehow.
Whether this is done with cookies of some kind, or by including server public
keys in SPF data, *shrug*...
I think it boils down to a problem that has been sitting in the "too hard"
basket for a very long time. It is going to be inconvenient no matter what,
but it has to be solved (being unable to verify senders is even more
inconvenient).
We can get away with the first two cases a lot of the time (I think), but the
third one is almost certain to crop up, and if it can be solved then it will
also conveniently cover the first two as well (and avoid the need for all
kinds of inconvenient responsibility-taking by lots of lusers).
> For example, the hp.com admin could have a whitelist that lists the
> entire pobox.com domain as okay for forwarding, since pobox.com is a
> trustworthy source. Theoretically, hp could do whitelisting for all
> of the forwarding services that their users use.
This is all well and good for "big boys", but does not scale. If we can, we
should solve the hard problem.
> However, in such a
> system, we'd probably want to also create DNS-based whitelists that
> list all reputable mailing-list and forwarding services that use SPF
> to reduce the workload on the SPF-enabled server admins. Perhaps in
> order to get on such a list, the forwarder owner would have to
> register directly with the whitelist so that email abuse through the
> forwarding system could be tracked. This sort of thing would also fix
> the mailing list problem, as they could register with the whitelists
> as well.
Whitelisting by IP? Not so great for people with dynamic IPs. How would you
run registration? How would you know that the person registering the server
was actually the server owner/operator?
If we do solve the hard problem, is SPF as currently conceived still useful?
A little? A lot? I'm not sure.
If not, then we'd do best to either solve the hard problem damn quick, or
just acknowledge that SPF can't be perfect and be rather more ruthless about
chucking out objections that can't be overcome (yet).
Cheers,
Nick
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@#Mo\HU;֤͵
|
