← Back to branch summary

~ubuntu-branches/ubuntu/feisty/dovecot/feisty-security

« back to all changes in this revision

Viewing changes to doc/auth-protocol.txt

  • Committer: Bazaar Package Importer
  • Author(s): Michael Vogt
  • Date: 2006-11-27 20:47:11 UTC
  • mfrom: (1.10.5 upstream)
  • Revision ID: james.westby@ubuntu.com-20061127204711-z7alg32xp4tnftjs
Tags: 1.0.rc15-1ubuntu1
* Merge from debian unstable. Remaining changes:
  - snakeoil ssl
  - Remove stop script symlinks from rc0 and rc6

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/auth-protocol.txt
100
100
 
101
101
 - lip=<local ip>    : Local IP  - in standard string format,
102
102
 - rip=<remote ip>   : Remote IP - ie. for IPv4 127.0.0.1 and for IPv6 ::1
103
 
 - resp=<base64>     : Initial response for authentication mechanism
104
103
 - secured           : Remote user has secured transport to auth client
105
104
                       (eg. localhost, SSL, TLS)
106
105
 - valid-client-cert : Remote user has presented a valid SSL certificate.
 
106
 - resp=<base64>     : Initial response for authentication mechanism.
 
107
                       NOTE: This must be the last parameter. Everything
 
108
                       after it is ignored. This is to avoid accidental
 
109
                       security holes if user-given data is directly put to
 
110
                       base64 string without filtering out tabs.
107
111
 
108
112
FAIL parameters may contain "reason=.." parameter which should be sent to
109
113
remote user instead of a standard "Authentication failed" message. For
146
150
 
147
151
 M: "REQUEST" TAB <id> TAB <client-pid> TAB <client-id>
148
152
 M: "USER" TAB <id> TAB <userid> TAB service=<service> [TAB <parameters>]
149
 
 M: "DIE"
150
153
 
151
154
 S: "NOTFOUND" TAB <id>
152
155
 S: "FAIL" TAB <id> TAB <error message>
161
164
ID is a connection-specific unique request identifier. It must be a 32bit
162
165
number, so typically you'd just increment it by one.
163
166
 
164
 
DIE makes the server stop accepting new requests, and as soon as the
165
 
existing requests are finished, it kills itself.
166
 
 
167
167
NOTFOUND reply means that the request or user wasn't found. Master
168
168
shouldn't even try to send REQUEST commands for nonexisting requests, so if
169
169
it happens it means either a timeout caused by very high load, or client