On Mon, 2004-12-06 at 18:34, David Woodhouse wrote:
I'm suggesting that one of
the flaws in the SPF draft -- that anyone with an account on a machine
which is listed can send 'authorised' mail -- could be alleviated by
having an _option_ to say that mail is only authorised if it comes from
a privileged port.
I see three types of solutions:
1. Publish valid outgoing ports that sending servers will use, and
make sure that your sending mail server users, and only your sending
mail server users (or programs), use those ports.
2. Publish lists of user IDs that may send mail from your machine, (or
publish a mapping of user IDs and valid user names), and set up your
identd server to answer queries about outgoing smtp servers
appropriately.
But in both the above cases, you're configuring ports and user id's that
are allowed to do something, publishing a ruleset, and asking *someone
else* to check the ruleset.
Since you have all the information available yourself, why not just do
egress checking yourself, and not burden the receiver?
To me that's the more reasonable solution, (and it doesn't require you
to expose your internal policies to the outside world):
3. Make sure that no mail *can* leave your machine that violates your
policies.
This means doing egress checking to prevent cross-customer
forgeries, for example, as well as spf egress checks, to make sure
that mail is never sent from your machine that would result in an
spf fail at the destination.
The simplest way of doing #3 is to firewall outgoing connections to
remote port 25's, requiring all code that makes such connections to go
through trusted code instead. (This assumes that your trusted mail
submission code follows your policies.)
Untrusted code that attempts to make outgoing port 25 connections
directly would then fail, or perhaps you could set up a local
transparent proxy through which trusted code would do the necessary
egress checking. (I think this makes the most sense, and I expect it to
become easier to do over time.)
Note that if you publish your "port from" rules, you're going to have to
make the same sort of decisions about the above, making sure that
activities that violate your policies are detectable by others, so
others can act upon them.
But if those policy violations made within your own machine are
detectable by others, instead of asking others to enforce your internal
policies, to me it makes more sense to just detect these violations and
enforce them yourself.
--
Mark Shewmaker
mark(_at_)primefactor(_dot_)com