On Monday 02 February 2004 5:13 pm, Wechsler wrote:
Dan Boresjo wrote:
Synopsis:
The %{u} macro expands to the username returned from an ident query
performed
on the incoming connection.
Dan -
I find the "explanation" that followed very confusing; you state above
that the macro expands to a username, and then later that it expands to
a uid or pid, and you provide no use cases. Likewise you start off
involving identd and then appear to discard it (generally the
appropriate action for identd, I've found).
The ident protocol is intended to return the remote account username of the
remote connecting process. The original identd did just that. However people
have written lots of variant identd daemons which return other things, like a
fake name etc.
Basically the protocol calls it a 'username' whilst in fact it is really just
a 'string' which could be anything, even a uid or pid. The point is that this
string is under the control of the idend and hence the administrator of the
host in question. So if you trust the admin but not all the users, the ident
string can be regarded as trusted.
SPF should not care about *what* the string returned by the remoted identd is,
all it needs to do is perform the macro substitution with the string
returned.
Do you expect this to be used in an exists: or a: rule, or what type?
Please give examples.
Yes. For example:
exists:%{u}.%{ir}.%{v}._spf.%{d2}
Assuming ident returns the username 'mail', the macro expands to:
mail.3.2.0.192.in-addr._spf.example.com
So the DNS server at _spf.example.com can decide if the 'mail' user at
192.0.2.3 is authorised to send mail from example.com.
Other accounts, like 'dan' or 'guest', on the host 192.0.2.3 would be denied
authorization.
As an example of using uids or pids rather than real usernames, let's say I
have a modified identd that returns a magic token of: md5(uid, hostip,
timeslot) where timeslot may change slowly, say once per hour.
Say the md5 hash for the 'mail' user on that host is currently
'49e86d99bea50d09c4657602a5de97f4' and was '97bff47c6742f560d76318f38b5cd7b5'
for the previous timeslot.
Then the same exists lookup would expand to:
49e86d99bea50d09c4657602a5de97f4.3.2.0.192.in-addr._spf.example.com
And the DNS server, knowing that 'mail' is the only authorised user for that
machine, would compare the ident string with one of two possible values:
md5('mail'.'192.0.2.3',$tsnow) = '49e86d99bea50d09c4657602a5de97f4'
md5('mail'.'192.0.2.3',$tslast) = '97bff47c6742f560d76318f38b5cd7b5'
Since the ident portion of the query matches a valid time recent token for
'mail' on that particular host, the DNS server at _spf.example.com can
authorize the connection.
As best I understand it you expect webservers to be able to interrogate
the DNS of a submitted email address to find out whether the
REMOTE_IP/REMOTE_PORT combination of an http session is legal for a
given user? (ok, so I don't understand it, I suspect). How is this
IP/PORT combination specified or returned?
No it just uses ident. Apache already includes support for ident as do some
SMTP servers.
For the perl implementation Mail::SPF::Query can use the Net::Ident package
See: http://www.xs4all.nl/~johnpc/perlstuff/Ident-1.20.html
Further this appears to have absolutely nothing to do with the core
purpose of SPF, which is to validate mail-sending machines.
That is just a special case of a more general problem: is the entity at the
remote end of an incoming connection a legitimate agent for the party it
claims to be acting on behalf of?
The %{u} provides a way to cope with the fact that certain perfectly
trustworthy machines have programs running under different user accounts. One
of these accounts (the standard UNIX 'mail' account) may be trusted to send
mail, but the user 'joe' may not be.
Imagine I have a single UNIX box on which I provide shell accounts and website
hosting facilities to clients (this includes email facilities). Users can,
for example, telnet to an smtp port anywhere in the world. Hoever they should
not do so with SPF's blessing. To send mail they pass it to sendmail where I
enforce a policy ensuring that no joe-jobs are performed. I want the 'mail'
account to be authorised to send mail from any domain, but a user account
should only send mail from domains they own, if at all.
I can do this with %{u}
Unless you can clarify the above points and explain in detail the
network mechanisms that allow a meaningful expansion of your macro, I
have to oppose it on the grounds of complexity and apparent irrelevance.
It is unclear and can only confuse the purpose of SPF and hamper adoption.
It removes two potential objections to SPF:
1) That multiuser hosts cannot be catered for.
2) That NAT'ed hosts and gateways cannot be catered for.
I think it is an amazingy powerful feature which adds little to the
implementation complexity.
- Dan
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.5.txt
Wiki: http://spfwiki.infinitepenguins.net/pmwiki.php/SenderPermittedFrom/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡