 |
| Prev-20 | Home | Next-20 |
| Prev-20 | Home | Next-20 |
| Prev-Msg | Prev-Thread | Postfix-users | May-2008 | Next-Thread | Next-Msg |
| Subject: | Re: Seperating SMTP and POP/IMAP services |
| Group: | Postfix-users |
| From: | Bill Cole |
| Date: | 8 May 2008 |
>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,re ject
>>
>>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
bill
| Prev-Msg | Prev-Thread | Postfix-users | May-2008 | Next-Thread | Next-Msg |