On Tue, May 31, 2016 at 05:04:33PM +0100, Rob Maidment wrote:

> How can I implement this in the Postfix SMTP server?
> 
> For certain client IP addresses no authentication is required and the
> EHLO response should not advertise the AUTH option.

    smtpd_discard_ehlo_keyword_address_maps     (auth,silent-discard)

> For a second set of client IP addresses authentication is required and
> the EHLO response should advertise AUTH PLAIN.

Postfix does not implement per-client SASL mechanism filters.  The
simplest solution is to direct each group clients that need
differentiated SASL service at a separate MSA.

The Dovecot SASL backend has access to the client's IP address,
but I don't know whether it sees that early enough to supply Postfix
with a client-dependent mechanism list, nor whether Dovecot has the
feature you're looking for.

> For a third set of client IP addresses authentication is required and
> the EHLO response should advertise AUTH LOGIN.

The two mechanisms being equivalent in all ways other than data
encapsulation, the requirement is rather strange.  It is simplest
to offer both to all clients.

> Clients in the third set must not be able to authenticate using the
> credentials defined for the second set, and vice versa.

This sounds like a much more substantial issue, you want to limit
certain clients to a specific set of SASL user-ids.  Sounds very
much like a use-case for a dedicated MSA.  Otherwise, you need a
SASL backend that exposes the desired client-dependent behaviour.
I don't known whether Cyrus SASL or Dovecot offer this kind of
personalization.

If you're willing to allow authentication to succeed with any valid
user-id, but limit relaying to a permitted combination of user-id
and client IP, that's doable with a policy service or restriction
classes.

        check_sasl_access <table>
        smtpd_restriction_classes = permit_client_A, permit_client_B
        permit_client_A = cidr:${config_directory}/client-a.cidr
        permit_client_B = cidr:${config_directory}/client-b.cidr

    <table>:
        us...@example.com       permit_client_A, reject_unauth_destination
        us...@example.com       permit_client_B, reject_unauth_destination

    client-a.cidr:
        192.0.2.0/25    OK

    client-b.cidr:
        192.0.2.128/25  OK

-- 
        Viktor.

Reply via email to