Re: ``WHY TAP?'': A White Paper

[Anders Andersson <[e-mail]>]

Ted writes:
>This is what my comment was referring to.  I believe the sendmail patch
>checks to see if the from address matches the username returned from the
>ident server, either rejects or marks the mail as being forged if it
>does not match.  This will clearly break if you are using encrypted
>Ident username tokens.  

I haven't examined the sendmail patch myself, but I think the procedure
outlined above would reject quite a lot of non-forged mail as well.
It's not always the case that the From: user owns the process performing
actual delivery, as it may have been queued up for some reason and
transmitted due to the actions of a system daemon.  If the message has
landed on an intermediary host, the 'user' performing actual delivery
has most likely nothing to do whatsoever with the user who originated
the message.

At most, the SMTP server receiving the message can log the IDENT token,
so it can be checked if a forgery is suspected.  The operator of the
SMTP server can then--after the fact--add a filter to reject or give
other special treatment to further SMTP connections coming from that
particular host and linked with that particular token, but that
assumes the tokens aren't uniquely generated for each connection to
be meaningful.

As I understand it, the SMTP server can be configured from the very
beginning to reject this kind of forgery (SMTP clients run by non-
authorized users) *only* upon agreement with the SMTP client operator
on which IDENT tokens should be assumed to represent authorized SMTP
client users.  There is no requirement that authorized users are
always called "root", "daemon" or something like that, and it's even
unlikely when we leave the Unix sphere.
--
Anders Andersson, Dept. of Computer Systems, Uppsala University
Paper Mail: Box 520, S-751 20 UPPSALA, Sweden
Phone: [phone]   EMail: [e-mail]