Seperating SMTP and POP/IMAP services

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Seperating SMTP and POP/IMAP services

David.Sharpe
Hi,

I have 2 instances of Postfix running on the same machine:

    mail.domain.com handles incoming email and forwarded email
    smtp.domain.com handles outgoing email

Users are instructed to use the smtp.domain.com for their outgoing
server, however some do not.
So I want to prevent these users from sending email over mail.domain.com
(wishlist: with a friendly message
which says please use smtp.domain.com).

What is the cleanest way of breaking this type of SMTP usage on
mail.domain.com whilst still allowing it to forward email.

Thanks,
David
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Seperating SMTP and POP/IMAP services

Victor Duchovni
On Thu, May 08, 2008 at 02:16:14PM +0100, David Sharpe wrote:

> Hi,
>
> I have 2 instances of Postfix running on the same machine:
>
>    mail.domain.com handles incoming email and forwarded email
>    smtp.domain.com handles outgoing email
>
> Users are instructed to use the smtp.domain.com for their outgoing
> server, however some do not.
> So I want to prevent these users from sending email over mail.domain.com
> (wishlist: with a friendly message
> which says please use smtp.domain.com).
>
> What is the cleanest way of breaking this type of SMTP usage on
> mail.domain.com whilst still allowing it to forward email.

Drop "permit_mynetworks" and/or "permit_sasl_authenticated" from the
recipient restrictions. The machine will then reject mail for domains
it is not responsible for (outgoing mail). Instead of leaving out
permit_mynetworks entirely, you can set mynetworks to just 127.0.0.1,
or a suitable IP range that excludes the users you want to restrict.

The message will be "Relay Access Denied". If you must have something
friendly:

    smtpd_client_restrictions =
        # assumes smtpd_delay_reject = yes (default)
        permit_auth_destination,
        check_client_access cidr:/etc/postfix/friendly_reject.cidr

friendly_reject.cidr:
    0.0.0.0/0 REJECT For outgoing mail, please use smtp.example.net

--
        Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:[hidden email]?body=unsubscribe%20postfix-users>

If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Seperating SMTP and POP/IMAP services

Bill Cole-3
In reply to this post by David.Sharpe
At 2:16 PM +0100 5/8/08, David Sharpe  imposed structure on a stream
of electrons, yielding:

>Hi,
>
>I have 2 instances of Postfix running on the same machine:
>
>    mail.domain.com handles incoming email and forwarded email
>    smtp.domain.com handles outgoing email
>
>Users are instructed to use the smtp.domain.com for their outgoing
>server, however some do not. So I want to prevent these users from
>sending email over mail.domain.com (wishlist: with a friendly message
>which says please use smtp.domain.com).

So, this is not really about splitting SMTP and POP/IMAP, but rather
about splitting inbound SMTP and mail submission SMTP. Right?

>What is the cleanest way of breaking this type of SMTP usage on
>mail.domain.com whilst still allowing it to forward email.

Probably the cleanest way would be to not have two distinct Postfix
instances, but rather to configure your port 25 smtp service to NOT
relay for $mynetworks (i.e. remove permit_mynetworks) and to NOT
offer authentication. To reject your own users politely, the cleanest
approach is probably to use smtpd_restriction_classes to define your
own users and give them a message that differs from whatever you'd
hand J. Random Zombie as a "no relaying" response.

For outbound mail, it is generally considered a best practice (if you
can do it...) to only offer a port 587 submission service that
requires authentication and usually TLS as well, since sniffer-safe
auth over unencrypted sessions has its own suite of problems. This
can be run alongside the inbound port 25 SMTP with a line in
master.cf like this:


submission      inet    n       -       n       -       -       smtpd
   -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes
   -o
smtpd_client_restrictions=permit_mynetworks,permit_sasl_authenticated,reject

NOTE: If I understand the master.cf man page correctly, you could and
maybe should clean that up a bit that by inventing a reasonable
parameter name like submit_rcpt_restrictions and using it like this:

submission      inet    n       -       n       -       -       smtpd
   -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes
   -o smtpd_client_restrictions=$submit_client_restrictions

Then you'd need an entry in main.cf like this:

submit_client_restrictions = permit_mynetworks,
        permit_sasl_authenticated,
        reject

NOTE 2: Depending on the nature of your network and users,
permit_mynetworks might well be a bit too trusting for the submission
service also.


--
Bill Cole                                  
[hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Seperating SMTP and POP/IMAP services

David.Sharpe
We were having a problem with users affecting our servers reputation by
forwarding their email onto their ISPs email server.  E.G to
Yahoo/BT/Gmail.  To tackle this (rightly or wrongly) we have separated
outgoing email onto a different IP address.

We are leaving forwarded email (E.G mail generated from a forward or an
alias) on the primary IP as this is considered 'dirty' and we cannot
guarantee we are not forwarding spam to other organisations.  Our
outgoing IP however is only sending email from our users to their
recipients (which is unlikely to be spam).

I think your description is inaccurate because 'mail submission smtp'
sounds like outgoing email to me, and there is still outgoing email,
just none originating from our user's MUAs.   Apologies if I have
misunderstood.

Bill Cole wrote:

> At 2:16 PM +0100 5/8/08, David Sharpe  imposed structure on a stream
> of electrons, yielding:
>> Hi,
>>
>> I have 2 instances of Postfix running on the same machine:
>>
>>    mail.domain.com handles incoming email and forwarded email
>>    smtp.domain.com handles outgoing email
>>
>> Users are instructed to use the smtp.domain.com for their outgoing
>> server, however some do not. So I want to prevent these users from
>> sending email over mail.domain.com (wishlist: with a friendly message
>> which says please use smtp.domain.com).
>
> So, this is not really about splitting SMTP and POP/IMAP, but rather
> about splitting inbound SMTP and mail submission SMTP. Right?
>
>> What is the cleanest way of breaking this type of SMTP usage on
>> mail.domain.com whilst still allowing it to forward email.
>
> Probably the cleanest way would be to not have two distinct Postfix
> instances, but rather to configure your port 25 smtp service to NOT
> relay for $mynetworks (i.e. remove permit_mynetworks) and to NOT offer
> authentication. To reject your own users politely, the cleanest
> approach is probably to use smtpd_restriction_classes to define your
> own users and give them a message that differs from whatever you'd
> hand J. Random Zombie as a "no relaying" response.
>
> For outbound mail, it is generally considered a best practice (if you
> can do it...) to only offer a port 587 submission service that
> requires authentication and usually TLS as well, since sniffer-safe
> auth over unencrypted sessions has its own suite of problems. This can
> be run alongside the inbound port 25 SMTP with a line in master.cf
> like this:
>
>
> submission      inet    n       -       n       -       -       smtpd
>   -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes
>   -o
> smtpd_client_restrictions=permit_mynetworks,permit_sasl_authenticated,reject
>
>
> NOTE: If I understand the master.cf man page correctly, you could and
> maybe should clean that up a bit that by inventing a reasonable
> parameter name like submit_rcpt_restrictions and using it like this:
>
> submission      inet    n       -       n       -       -       smtpd
>   -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes
>   -o smtpd_client_restrictions=$submit_client_restrictions
>
> Then you'd need an entry in main.cf like this:
>
> submit_client_restrictions = permit_mynetworks,
>     permit_sasl_authenticated,
>     reject
>
> NOTE 2: Depending on the nature of your network and users,
> permit_mynetworks might well be a bit too trusting for the submission
> service also.
>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Seperating SMTP and POP/IMAP services

David.Sharpe
In reply to this post by Victor Duchovni
Hi Victor,

And this will still all forwards? E.G
    [hidden email] -> [hidden email]

Thanks,
David


Victor Duchovni wrote:

> On Thu, May 08, 2008 at 02:16:14PM +0100, David Sharpe wrote:
>
>  
>> Hi,
>>
>> I have 2 instances of Postfix running on the same machine:
>>
>>    mail.domain.com handles incoming email and forwarded email
>>    smtp.domain.com handles outgoing email
>>
>> Users are instructed to use the smtp.domain.com for their outgoing
>> server, however some do not.
>> So I want to prevent these users from sending email over mail.domain.com
>> (wishlist: with a friendly message
>> which says please use smtp.domain.com).
>>
>> What is the cleanest way of breaking this type of SMTP usage on
>> mail.domain.com whilst still allowing it to forward email.
>>    
>
> Drop "permit_mynetworks" and/or "permit_sasl_authenticated" from the
> recipient restrictions. The machine will then reject mail for domains
> it is not responsible for (outgoing mail). Instead of leaving out
> permit_mynetworks entirely, you can set mynetworks to just 127.0.0.1,
> or a suitable IP range that excludes the users you want to restrict.
>
> The message will be "Relay Access Denied". If you must have something
> friendly:
>
>     smtpd_client_restrictions =
> # assumes smtpd_delay_reject = yes (default)
> permit_auth_destination,
> check_client_access cidr:/etc/postfix/friendly_reject.cidr
>
> friendly_reject.cidr:
>     0.0.0.0/0 REJECT For outgoing mail, please use smtp.example.net
>
>  

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Seperating SMTP and POP/IMAP services

Bill Cole-3
In reply to this post by David.Sharpe
At 5:29 PM +0100 5/8/08, David Sharpe wrote:
>We were having a problem with users affecting our servers reputation
>by forwarding their email onto their ISPs email server.  E.G to
>Yahoo/BT/Gmail.  To tackle this (rightly or wrongly) we have
>separated outgoing email onto a different IP address.

OK, so that justifies distinct instances on different IP's. One
instance handles the mail that originates with your users, the other
handles mail addressed to your users inbound and any forwarding of
that mail outbound. That makes sense.

>We are leaving forwarded email (E.G mail generated from a forward or
>an alias) on the primary IP as this is considered 'dirty' and we
>cannot guarantee we are not forwarding spam to other organisations.
>Our outgoing IP however is only sending email from our users to
>their recipients (which is unlikely to be spam).

I'm guessing that you haven't seen many Swen-infested users, but
that's a different problem....


>I think your description is inaccurate because 'mail submission
>smtp' sounds like outgoing email to me, and there is still outgoing
>email, just none originating from our user's MUAs.   Apologies if I
>have misunderstood.

Maybe, maybe not.

There is a nomenclature problem with initial mail submission by MUA's
because while historically it has usually been done using SMTP on
port 25, there is a derivative of SMTP (latest spec: rfc4409) just
for message submission (i.e. for MUA's to use) which differs from
SMTP chiefly in the norms of policy and the port it runs on rather
than protocol semantics, so it is typically handled by a SMTP server
(e.g. Postfix's smtpd) and not some specialized submission server.
How one refers to the message submission protocol can be confusing,
because there's not a clear and concise way to communicate that it is
a subset of SMTP plus a couple of common extensions, but running on a
different reserved port and using a different set of policy
assumptions, for use by MUA's. Mail being forwarded through your MTA
because of .forward files or aliases is not using the submission
protocol when you pass it along.

Clear as mud, most likely... In any case, this isn't about POP or
IMAP because those are only involved in users accessing delivered
mail.


>Bill Cole wrote:
>>At 2:16 PM +0100 5/8/08, David Sharpe  imposed structure on a
>>stream of electrons, yielding:
>>>Hi,
>>>
>>>I have 2 instances of Postfix running on the same machine:
>>>
>>>    mail.domain.com handles incoming email and forwarded email
>>>    smtp.domain.com handles outgoing email
>>>
>>>Users are instructed to use the smtp.domain.com for their outgoing
>>>server, however some do not. So I want to prevent these users from
>>>sending email over mail.domain.com (wishlist: with a friendly
>>>message
>>>which says please use smtp.domain.com).
>>
>>So, this is not really about splitting SMTP and POP/IMAP, but
>>rather about splitting inbound SMTP and mail submission SMTP. Right?
>>
>>>What is the cleanest way of breaking this type of SMTP usage on
>>>mail.domain.com whilst still allowing it to forward email.
>>
>>Probably the cleanest way would be to not have two distinct Postfix
>>instances, but rather to configure your port 25 smtp service to NOT
>>relay for $mynetworks (i.e. remove permit_mynetworks) and to NOT
>>offer authentication. To reject your own users politely, the
>>cleanest approach is probably to use smtpd_restriction_classes to
>>define your own users and give them a message that differs from
>>whatever you'd hand J. Random Zombie as a "no relaying" response.
>>
>>For outbound mail, it is generally considered a best practice (if
>>you can do it...) to only offer a port 587 submission service that
>>requires authentication and usually TLS as well, since sniffer-safe
>>auth over unencrypted sessions has its own suite of problems. This
>>can be run alongside the inbound port 25 SMTP with a line in
>>master.cf like this:
>>
>>
>>submission      inet    n       -       n       -       -       smtpd
>>   -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes
>>   -o
>>smtpd_client_restrictions=permit_mynetworks,permit_sasl_authenticated,reject
>>
>>NOTE: If I understand the master.cf man page correctly, you could
>>and maybe should clean that up a bit that by inventing a reasonable
>>parameter name like submit_rcpt_restrictions and using it like this:
>>
>>submission      inet    n       -       n       -       -       smtpd
>>   -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes
>>   -o smtpd_client_restrictions=$submit_client_restrictions
>>
>>Then you'd need an entry in main.cf like this:
>>
>>submit_client_restrictions = permit_mynetworks,
>>     permit_sasl_authenticated,
>>     reject
>>
>>NOTE 2: Depending on the nature of your network and users,
>>permit_mynetworks might well be a bit too trusting for the
>>submission service also.


--
Bill Cole                                  
[hidden email]

Loading...