begin Thursday 22 April 2004 14:41, Theo Schlossnagle quote:
These are apples and oranges. The results of these compromises have
entirely different security implications. A forwarder using SRS was
granted no rights (or trust) by you and thus those rights can't be
abused. A trusted forwarder who is compromised inherently gains the
advantage of whatever trust was awards to that forwarder.
... and that's not a big trust in any way.
In the "whitelist" example, the forwarder is merely trusted with the
right to "use any From domain when sending mail to one specific user".
That's a far weaker trust than what most MTA hosts extend to *any*
other MTA host on the net right now: "use any From domain when sending
mail to any of our users".
Note that ~/.trusted-forwarder doesn't grant the right to abuse the
MTA as an open relay.
So, I fail to see how it is such a big problem if the (rather
limited) trust granted by ~/.trusted-forwarder is abused.
Moreover, if a forwarder is compromised (as in "root privileges fell
into wrong hands"), the user who trusts this forwarder has far worse
problems to worry about than increased just spam: indeed, the user's
address _at_that_forwarder_ is still in all (most of) his friend's
address books, thus the compromising party will be able to snoop on
his incoming mail.
These solutions need to be widespread to work, so "only those who have
trusted a forwarder" will, hopefully, be a huge list of people.
Correct, but it will not be the same forwarder for everybody. Any
given forwarder will only be trusted by its customers.
And
quite dynamic from small site to small site. It is tough to track and
each admin on each site must be aware of the integrity of each
forwarder they trust -- that is a lot to ask. All the while, the trust
that was award to that forwarder was to use _any_ domain name in their
return path -- the trust is that they won't use it fraudulently.
Actually, implicitly the users of a forwarder grant a far greater
trust to it: not to divulg their private correspondence to a third
party, and not to maliciously change its contents!
--
That being said, I see a different issue with these per-user
whitelists:
In some MTAs, such as sendmail, it is surprisingly difficult to find
out the final recipient at the early stage of mail submission at which
the milter is invoked. The rcpt_to callback passes the user name as
submitted by the previous MTA, without any alias or virtusertable
expansion.
So, either the milter would need to do this itself (with the risk of
accidentally getting the alias/virtuser expansion algorithm slightly
different than sendmail itself), or we would need to instruct the
users to only forward to his login(_at_)mydomain(_dot_)com address, and never to
FirstName(_dot_)Lastname(_at_)mydomain(_dot_)com or
FirstName(_at_)myvanitydomain(_dot_)com
Alain