2006-01-26 22:36:34 +01:00
|
|
|
#
|
2009-02-11 07:18:09 +01:00
|
|
|
# read this with 'perldoc authentication.pod' ...
|
2006-01-26 22:36:34 +01:00
|
|
|
#
|
2004-06-29 23:45:35 +02:00
|
|
|
|
|
|
|
=head1 NAME
|
|
|
|
|
2006-01-26 22:36:34 +01:00
|
|
|
Authentication framework for qpsmtpd
|
2004-06-29 23:45:35 +02:00
|
|
|
|
|
|
|
=head1 DESCRIPTION
|
|
|
|
|
|
|
|
Provides support for SMTP AUTH within qpsmtpd transactions, see
|
|
|
|
|
2005-04-12 21:59:52 +02:00
|
|
|
L<http://www.faqs.org/rfcs/rfc2222.html>
|
|
|
|
L<http://www.faqs.org/rfcs/rfc2554.html>
|
2004-06-29 23:45:35 +02:00
|
|
|
|
|
|
|
for more details.
|
|
|
|
|
|
|
|
=head1 USAGE
|
|
|
|
|
2006-01-26 22:36:34 +01:00
|
|
|
This code is automatically loaded by Qpsmtpd::SMTP only if a plugin
|
2004-06-29 23:45:35 +02:00
|
|
|
providing one of the defined L<Auth Hooks> is loaded. The only
|
|
|
|
time this can happen is if the client process employs the EHLO command to
|
|
|
|
initiate the SMTP session. If the client uses HELO, the AUTH command is
|
|
|
|
not available and this module isn't even loaded.
|
|
|
|
|
|
|
|
=head2 Plugin Design
|
|
|
|
|
|
|
|
An authentication plugin can bind to one or more auth hooks or bind to all
|
|
|
|
of them at once. See L<Multiple Hook Behavior> for more details.
|
|
|
|
|
|
|
|
All plugins must provide two functions:
|
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
2006-01-26 22:36:34 +01:00
|
|
|
=item * init()
|
2004-06-29 23:45:35 +02:00
|
|
|
|
|
|
|
This is the standard function which is called by qpsmtpd for any plugin
|
|
|
|
listed in config/plugins. Typically, an auth plugin should register at
|
|
|
|
least one hook, like this:
|
|
|
|
|
|
|
|
|
2006-01-26 22:36:34 +01:00
|
|
|
sub init {
|
2004-06-29 23:45:35 +02:00
|
|
|
my ($self, $qp) = @_;
|
|
|
|
|
|
|
|
$self->register_hook("auth", "authfunction");
|
|
|
|
}
|
|
|
|
|
|
|
|
where in this case "auth" means this plugin expects to support any of
|
|
|
|
the defined authentication methods.
|
|
|
|
|
|
|
|
=item * authfunction()
|
|
|
|
|
|
|
|
The plugin must provide an authentication function which is part of
|
|
|
|
the register_hook call. That function will receive the following
|
|
|
|
six parameters when called:
|
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
|
|
|
=item $self
|
|
|
|
|
|
|
|
A Qpsmtpd::Plugin object, which can be used, for example, to emit log
|
|
|
|
entries or to send responses to the remote SMTP client.
|
|
|
|
|
|
|
|
=item $transaction
|
|
|
|
|
|
|
|
A Qpsmtpd::Transaction object which can be used to examine information
|
|
|
|
about the current SMTP session like the remote IP address.
|
|
|
|
|
Changes by jpeacock@cpan.org (John Peacock)
o plugins/check_badmailfromto
- New plugin in the style of check_badmailfrom, which matches a pair
of FROM/TO and makes it seem like the recipient's address no longer
exists (but only from the matching sender's point of view). Useful
for stalkers and other harassment cases.
o plugins/dns_whitelist_soft
- New plugin to provide a DNS-based whitelist (good for distributed
sites).
o various files
- Replaced tab character with 8 spaces and adjusted line breaks for
better readability.
Changes by mct@toren.net (Michael C. Toren)
o lib/Qpsmtpd/SMTP.pm
- Assumes a MAIL FROM value of "<#@[]>" (utilized by qmail to
indicate a null sender when generating a doublebounce message)
is equivalent to "<>". Previously qpsmtpd complained that the
value could not be parsed.
- Adds LOGIN to the default list of supported auth mechanisms.
The documentation in Auth.pm indicated that auth-login was not
currently supported due to lack of functionality, however I can
confirm that LOGIN appears to work fine as tested by using msmtp
(http://msmtp.sourceforge.net/). Are there any indications that
LOGIN support is actually broken in the current implementation?
- Removes the "X-Qpsmtpd-Auth: True" header appended when a message
has been sent by an authenticated user. One problem with such a
header is that it's impossible to say which SMTP hop added it,
and it provides no information which could be used to backtrack
the transaction. I grepped through my mail archives a bit
looking for how other MTAs handled the problem, and decided it
would be best to place this information in the Received: header:
Received: from remotehost (HELO remotehost) (192.168.42.42)
(smtp-auth username foo, mechanism cram-md5)
by mail.netisland.net (qpsmtpd/0.28) with ESMTP; <date>
o lib/Qpsmtpd/Auth.pm:
- Documentation update for the arguments passed to an auth
handler; previously the $mechanism argument was not mentioned,
which threw off the argument offsets.
- Documentation update for auth-login removing the warning
that auth-login is not currently supported due to lack of
functionality.
- Fix to execute a generic auth hook when a more specific
auth-$mechanism hook does not exist. (Previously posted
to the list last week.)
- Upon authentication, sets $session->{_auth_user} and
$session->{_auth_mechanism} so that SMTP.pm can include them
in the Received: header.
o plugins/queue/qmail-queue
- Added a timestamp and the qmail-queue qp identifier to the
"Queued!" 250 message, for compatibility with qmail-smtpd, which
can be very useful for tracking message delivery from machine to
machine. For example, the new 250 message might be:
250 Queued! 1105927468 qp 3210 <1105927457@netisland.net>
qmail-smtpd returns:
250 ok 1106546213 qp 7129
Additionally, for consistency angle brackets are placed around
the Message-ID displayed in the 250 if they were missing in the
message header.
o plugins/check_badmailfrom:
- Changed the error message from "Mail from $bad not accepted
here" to "sorry, your envelope sender is in my badmailfrom
list", for compatibility with qmail-smtpd. I didn't see any
reason to share with the sender the value of $bad, especially
for situations where the sender was rejected resulting from a
wildcard.
o plugins/check_earlytalker:
o plugins/require_resolvable_fromhost:
- No longer checks for earlytalkers or resolvable senders if the
connection note "whitelistclient" is set, which is nice for
helping backup MX hosts empty their queue faster.
o plugins/count_unrecognized_commands:
- Return code changed from DENY_DISCONNECT, which isn't valid in
an unrecognized_command hook, to DENY, which in this context
drops the connection anyway. (Previously posted to the list
last week.)
git-svn-id: https://svn.perl.org/qpsmtpd/trunk@356 958fd67b-6ff1-0310-b445-bb7760255be9
2005-01-28 04:30:50 +01:00
|
|
|
=item $mechanism
|
|
|
|
|
|
|
|
The lower-case name of the authentication mechanism requested by the
|
|
|
|
client; either "plain", "login", or "cram-md5".
|
|
|
|
|
2004-06-29 23:45:35 +02:00
|
|
|
=item $user
|
|
|
|
|
|
|
|
Whatever the remote SMTP client sent to identify the user (may be bare
|
|
|
|
name or fully qualified e-mail address).
|
|
|
|
|
|
|
|
=item $clearPassword
|
|
|
|
|
|
|
|
If the particular authentication method supports unencrypted passwords
|
|
|
|
(currently PLAIN and LOGIN), which will be the plaintext password sent
|
|
|
|
by the remote SMTP client.
|
|
|
|
|
|
|
|
=item $hashPassword
|
|
|
|
|
|
|
|
An encrypted form of the remote user's password, using the MD-5 algorithm
|
|
|
|
(see also the $ticket parameter).
|
|
|
|
|
|
|
|
=item $ticket
|
|
|
|
|
|
|
|
This is the cryptographic challenge which was sent to the client as part
|
|
|
|
of a CRAM-MD5 transaction. Since the MD-5 algorithm is one-way, the same
|
|
|
|
$ticket value must be used on the backend to compare with the encrypted
|
|
|
|
password sent in $hashPassword.
|
|
|
|
|
|
|
|
=back
|
|
|
|
|
|
|
|
=back
|
|
|
|
|
|
|
|
Plugins should perform whatever checking they want and then return one
|
|
|
|
of the following values (taken from Qpsmtpd::Constants):
|
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
|
|
|
=item OK
|
|
|
|
|
|
|
|
If the authentication has succeeded, the plugin can return this value and
|
|
|
|
all subsequently registered hooks will be skipped.
|
|
|
|
|
2005-04-12 21:59:52 +02:00
|
|
|
=item DECLINED
|
2004-06-29 23:45:35 +02:00
|
|
|
|
|
|
|
If the authentication has failed, but any additional plugins should be run,
|
|
|
|
this value will be returned. If none of the registered plugins succeed, the
|
2005-04-12 21:59:52 +02:00
|
|
|
overall authentication will fail. Normally an auth plugin should return
|
|
|
|
this value for all cases which do not succeed (so that another auth plugin
|
|
|
|
can have a chance to authenticate the user).
|
2004-06-29 23:45:35 +02:00
|
|
|
|
|
|
|
=item DENY
|
|
|
|
|
|
|
|
If the authentication has failed, and the plugin wishes this to short circuit
|
|
|
|
any further testing, it should return this value. For example, a plugin could
|
|
|
|
register the L<auth-plain> hook and immediately fail any connection which is
|
2005-04-12 21:59:52 +02:00
|
|
|
not trusted (e.g. not in the same network).
|
2004-06-29 23:45:35 +02:00
|
|
|
|
2005-04-12 21:59:52 +02:00
|
|
|
Another reason to return DENY over DECLINED would be if the user name matched
|
2004-06-29 23:45:35 +02:00
|
|
|
an existing account but the password failed to match. This would make a
|
2005-04-12 21:59:52 +02:00
|
|
|
dictionary-based attack much harder to accomplish. See the included
|
|
|
|
auth_vpopmail_sql plugin for how this might be accomplished.
|
2004-06-29 23:45:35 +02:00
|
|
|
|
|
|
|
By returning DENY, no further authentication attempts will be made using the
|
|
|
|
current method and data. A remote SMTP client is free to attempt a second
|
|
|
|
auth method if the first one fails.
|
|
|
|
|
|
|
|
=back
|
|
|
|
|
|
|
|
Plugins may also return an optional message with the return code, e.g.
|
|
|
|
|
|
|
|
return (DENY, "If you forgot your password, contact your admin");
|
|
|
|
|
|
|
|
and this will be appended to whatever response is sent to the remote SMTP
|
|
|
|
client. There is no guarantee that the end user will see this information,
|
|
|
|
though, since some prominent MTA's (produced by M$oft) I<helpfully>
|
|
|
|
hide this information under the default configuration. This message will
|
2005-04-12 21:59:52 +02:00
|
|
|
be logged locally, if appropriate, based on the configured log level.
|
2004-06-29 23:45:35 +02:00
|
|
|
|
|
|
|
=head1 Auth Hooks
|
|
|
|
|
|
|
|
The currently defined authentication methods are:
|
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
|
|
|
=item * auth-plain
|
|
|
|
|
|
|
|
Any plugin which registers an auth-plain hook will engage in a plaintext
|
|
|
|
prompted negotiation. This is the least secure authentication method since
|
|
|
|
both the user name and password are visible in plaintext. Most SMTP clients
|
2005-04-12 21:59:52 +02:00
|
|
|
will preferentially choose a more secure method if it is advertised by the
|
2004-06-29 23:45:35 +02:00
|
|
|
server.
|
|
|
|
|
|
|
|
=item * auth-login
|
|
|
|
|
|
|
|
A slightly more secure method where the username and password are Base-64
|
|
|
|
encoded before sending. This is still an insecure method, since it is
|
|
|
|
trivial to decode the Base-64 data. Again, it will not normally be chosen
|
|
|
|
by SMTP clients unless a more secure method is not available (or if it fails).
|
|
|
|
|
|
|
|
=item * auth-cram-md5
|
|
|
|
|
|
|
|
A cryptographically secure authentication method which employs a one-way
|
|
|
|
hashing function to transmit the secret information without significant
|
|
|
|
risk between the client and server. The server provides a challenge key
|
|
|
|
L<$ticket>, which the client uses to encrypt the user's password.
|
|
|
|
Then both user name and password are concatenated and Base-64 encoded before
|
|
|
|
transmission.
|
|
|
|
|
|
|
|
This hook must normally have access to the user's plaintext password,
|
|
|
|
since there is no way to extract that information from the transmitted data.
|
|
|
|
Since the CRAM-MD5 scheme requires that the server send the challenge
|
|
|
|
L<$ticket> before knowing what user is attempting to log in, there is no way
|
|
|
|
to use any existing MD5-encrypted password (like is frequently used with MySQL).
|
|
|
|
|
|
|
|
=item * auth
|
|
|
|
|
|
|
|
A catch-all hook which requires that the plugin support all three preceeding
|
|
|
|
authentication methods. Any plugins registering the auth hook will be run
|
|
|
|
only after all other plugins registered for the specific authentication
|
|
|
|
method which was requested. This allows you to move from more specific
|
|
|
|
plugins to more general plugins (e.g. local accounts first vs replicated
|
|
|
|
accounts with expensive network access later).
|
|
|
|
|
|
|
|
=back
|
|
|
|
|
|
|
|
=head2 Multiple Hook Behavior
|
|
|
|
|
|
|
|
If more than one hook is registered for a given authentication method, then
|
|
|
|
they will be tried in the order that they appear in the config/plugins file
|
|
|
|
unless one of the plugins returns DENY, which will immediately cease all
|
|
|
|
authentication attempts for this transaction.
|
|
|
|
|
|
|
|
In addition, all plugins that are registered for a specific auth hook will
|
|
|
|
be tried before any plugins which are registered for the general auth hook.
|
|
|
|
|
2010-05-11 08:19:05 +02:00
|
|
|
=head1 VPOPMAIL
|
|
|
|
|
|
|
|
There are 4 authentication (smtp-auth) plugins that can be used with
|
|
|
|
vpopmail.
|
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
|
|
|
=item auth_vpopmaild
|
|
|
|
|
|
|
|
If you aren't sure which one to use, then use auth_vpopmaild. It
|
|
|
|
has full support for all 3 authentication methods (PLAIN,LOGIN,CRAM-MD5),
|
|
|
|
doesn't require the qpsmtpd process to run with special permissions, and
|
|
|
|
can authenticate against vpopmail running on another host. It does require
|
|
|
|
the vpopmaild server to be running.
|
|
|
|
|
|
|
|
=item auth_vpopmail
|
|
|
|
|
|
|
|
The next best solution is auth_vpopmail. It requires the p5-vpopmail perl
|
|
|
|
module and it compiles against libvpopmail.a. There are two catches. The
|
|
|
|
qpsmtpd daemon must run as the vpopmail user, and you must be running v0.09
|
|
|
|
or higher for CRAM-MD5 support. The released version is 0.08 but my
|
|
|
|
CRAM-MD5 patch has been added to the developers repo:
|
|
|
|
http://github.com/sscanlon/vpopmail
|
|
|
|
|
|
|
|
=item auth_vpopmail_sql
|
|
|
|
|
|
|
|
If you are using the MySQL backend for vpopmail, then this module can be
|
|
|
|
used for smtp-auth. It has support for all three auth methods. However, it
|
|
|
|
does not work with some vpopmail features such as alias domains, service
|
|
|
|
restrictions, nor does it update vpopmail's last_auth information.
|
|
|
|
|
|
|
|
=item auth_checkpassword
|
|
|
|
|
|
|
|
The auth_checkpassword is a generic authentication module that will work
|
|
|
|
with any DJB style checkpassword program, including ~vpopmail/bin/vchkpw.
|
|
|
|
It only supports PLAIN and LOGIN auth methods.
|
|
|
|
|
|
|
|
=back
|
|
|
|
|
2004-06-29 23:45:35 +02:00
|
|
|
=head1 AUTHOR
|
|
|
|
|
|
|
|
John Peacock <jpeacock@cpan.org>
|
|
|
|
|
2010-05-11 08:19:05 +02:00
|
|
|
Matt Simerson <msimerson@cpan.org> (added VPOPMAIL)
|
|
|
|
|
2004-06-29 23:45:35 +02:00
|
|
|
=head1 COPYRIGHT AND LICENSE
|
|
|
|
|
2006-01-26 22:36:34 +01:00
|
|
|
Copyright (c) 2004-2006 John Peacock
|
2004-06-29 23:45:35 +02:00
|
|
|
|
|
|
|
Portions based on original code by Ask Bjoern Hansen and Guillaume Filion
|
|
|
|
|
|
|
|
This plugin is licensed under the same terms as the qpsmtpd package itself.
|
|
|
|
Please see the LICENSE file included with qpsmtpd for details.
|
|
|
|
|
|
|
|
=cut
|