Re: Virtual delivery + procmail

[Gerard]

On Thu, 30 Apr 2009 10:57:57 -0700 (PDT)
Jordan Tardif  wrote:

>> Perhaps you are using the wrong mail system?
>>
>> .-.
>> |agent |executes commands|requires UNIX system acounts|
>> |-|
>> |virtual(8)|no   | no |
>> |pipe(8)   |yes  | knows nothing about users  |
>> |local(8)  |yes  | yes|
>> `-'
>
>The problem is we have users with diffrent uid's/gid's via 
>virtual_uid_maps and virtual_gid_maps. The mail gets delivered as
>those users, but you have no way to run procmail etc as that user.
>
>Do you know of some way to get procmail to run as the specific user
>with an alias like..
>
>| blah--spentgraphics.com  |
>|"/usr/bin/procmail /home/user/.procmailrc" | spentgraphics.com |
>
>As far as I can see there is no way to get postfix to exec this
>procmail command as the virutal user. Am I missing something here?

Do you really have to use procmail? I never liked it. It is a memory
hog and has a nasty "fall through" habit. Why not use something like
dovecot. It has filtering rules and integrates seamlessly with postfix.

-- 
Gerard
postfix.u...@yahoo.com

TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail
TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html

This is clearly another case of too many mad scientists,
and not enough hunchbacks.


signature.asc
Description: PGP signature

Re: Suggestions on submission port config

[Jorey Bump]

Scott Haneda wrote, at 04/30/2009 10:31 PM:>
> On Apr 24, 2009, at 9:43 PM, Jorey Bump wrote:
>>
>> Since one of the purposes of the submission port is to support road
>> warriors, I feel it should be as secure as possible and the entire
>> communication should be encrypted.
> 
> I am in a bad spot in this regard, because of some of the faults of my
> current email server.  It is pushed a bit to move users to 587, but the
> server does not support SSL/TLS.  It would be very hard for me to get
> them to all change their settings to use SSL/TLS.  I would love to make
> 587 the default secure port, I just do not thing I can put my users in
> that situation.
> 
> If postfix can log in a way that I can tell what is going on, and over
> time, I can make a call a day, and convert people over to TLS,
> eventually I will flip this switch.

You can alter the name syslog uses for the submission service by adding:

  -o syslog_name=postfix-submission

I recommend setting up port 587 correctly and securely from the start
and migrating users gradually. Since they are already changing
configuration settings, have them switch to TLS at the same time, so it
doesn't have to be dealt with later. The new log name will aid in
troubleshooting. You'll be able to tell who is still authenticating on
port 25 because it will be logged under a different name. Just grep for
sasl_username in your logs.

>> In some cases, I allow the use of a secure mechanism without TLS on port
>> 25. This protects the login, but not the message contents. I don't allow
>> unencrypted plaintext logins.
> 
> I am leaning back on this idea again.  Have to hash that out from the
> standpoint of a proxy.  I am just do not know if I gain anything by
> putting all user MUA traffic on a non port 25 port.  I know the proxy
> tries to learn from users sending emails, and white list the recipients,
> I do not know if that learning is port bound or not.

Well, that's another potential advantage of using port 587: you can
spare authenticated users (and your system) from filter/proxy scans.

Note that some environments still want to scan outgoing mail. Once
again, the fact that you're using an alternate port allows you to
customize settings to suit the purpose, so it can be another win.

>> It's up to you. I use SMTP AUTH for webmail, partly because it provides
>> better logging for troubleshooting.
> 
> Good point.  What webmail are you using?  Does it globally SMTP AUTH via
> a config file and a smtp account, or is each user login it's own SMTP
> AUTH case, which is where you are picking up the logging data specific
> to the sender under that specific account?

I use SquirrelMail, which uses individual login credentials for both
IMAP access and SMTP AUTH. It's nice to have the user information in the
logs. In fact, if you are using Roundcube, make sure it's fully patched.
There is a vulnerability that is still being probed for daily against
likely locations for it on web servers.

>> Default autoconfiguration appears to use ports 25, 465, & 587 and SSL if
>> detected. The server I tested supports all of these and the mechanism
>> list is PLAIN LOGIN CRAM-MD5 DIGEST-MD5. After autoconfiguration, Apple
>> Mail used STARTTLS and the PLAIN mechanism on port 25 to send a message.
> 
> Are there are good reasons to support PLAIN and LOGIN and PASSWORD?  I
> have told all our users to use MD5 Challenge Response.  Maybe I would
> aid Apple Mail in figuring out which to pick, it seems to always fall
> back on PASSWORD iirc.  Perhaps other desktop clients do not support md5
> mechanisms.

PLAIN & LOGIN are almost universally supported, and are safe to use over
an encrypted channel. If you force encryption for plaintext logins, you
get peace of mind and your users get more flexibility when configuring
clients (which I've found to be a big win as they point and click randomly).

I've also had to support some "enterprise" applications that have
severely limited SMTP capabilities, so this extra flexibility comes in
handy.

> A friend of mine signed up for some cheapo hosting account, and they had
> a apple script to set it up.  It did not work, but I have been meaning
> to swipe it and fix it.  It looks very simple to deal with, and you can
> shove the users login name in, so all they do is run it, connect to get
> email, enter in their password, and click "remember" and they are done.
> 
> I would bet I can alter the default port in this script as well.

That's one option, but you might be better off going with the
autoconfiguration and providing instructions where that fails. Asking
users to run scripts is sending the wrong message, IMHO. It just makes
them more vulnerable to phishing and other exploits that rely on bad
practice.

>> You'll have to refer to your SASL implementation to see what mechanisms
>> you can support. There can be some additional overhead with the secure
>> mechanisms, but it's nice to have the flexibility. Also, some MUAs
>> behaved unpredictably when 

Re: Suggestions on submission port config

[Jorey Bump]

Scott Haneda wrote, at 04/30/2009 10:11 PM:

> What happens is, under heavy MTA load on port 25, I will run out of
> connection slots on port 25.

Have you investigated the nature of this problem?

> By moving users to 587, I do not care
> about port 25 connection slots.  MTA's will try again later if busy.

You might be chasing a red herring. If your server is overloaded, there
is a reason why, and there may be more effective remediation techniques
available. Improving your submission service is good, but it might not
deliver the performance payoff you're expecting.

> What do you guys think?
> 
> My end goal here is to get this all working, and then change these ports
> to, for example, 25 -> 2525 and 587 -> 587587 unless there is some other
> convention.  I am going to put a anti spam proxy in front of all this.

If you still have a heavy load, consider separating your MX entirely
from submission, using separate instances/machines. It's generally
easier to move the MX, since MUA configurations don't care about it.

> I just do not want to add too much to my learning curve, so first, get
> postfix to where I understand it, then toggle the ports and put the
> proxy in.  It should blindly pass the traffic, I assume in much the same
> way stunnel does.
> 
> I am open to any and all advice on this matter to make this work best. 
> I have a feeling later on down the road I will need to learn exactly
> what things to disable in postfix, as it should not do any bouncing at
> all, anything that will lead to backsplatter, since I am putting a proxy
> ahead of it.

FWIW, a poorly implemented proxy can do more harm than good. A lot of
sites just toss them in, and don't pay attention to finer details like
DNS settings and recipient validation.

> I am still not entirely clear.  The docs:
>  I am still not entirely clear. The docs: "Do not configure client
>  certificates unless you must present client TLS certificates to one or
>  more servers. Client certificates are not usually needed, and can
> cause
>  problems in configurations that work well without them. The
> recommended
>  setting is to let the defaults stand"
> 
> That supports your statement.  What is confusing, is most of the
> tutorials for setting up Postfix have a section on setting these up. 

Trust the Postfix documentation, not random tutorials.

> Indeed, the ones I set up used a specific host name, and when I  smtp,
> or pop or imap, I am asked to authorize the self signed cert, as at this
> time I do not have a purchased cert from a CA.

That's something else. You get that prompt from the server certificate
(smtpd_tls_cert_file), which you need. That is different from the client
certificate (smtp_tls_cert_file), which you obviously don't need.

> What is the correct way to not use certs for MTA's, but to present one
> to the MUA?
>
>> # server TLS parameters
>> smtpd_tls_key_file = /etc/ssl/yoshino.meidokon.net_key
>> smtpd_tls_cert_file = /etc/ssl/yoshino.meidokon.net_crt
>> smtpd_tls_auth_only = yes  <-- as mentioned, user can only auth on a
>> secure connection
>> smtpd_tls_loglevel = 1
>> smtpd_tls_received_header = yes
> 
> You have the two cert, ahhh, smtp*d*.  Ok, I think I get it, that is for
> MUA traffic, and you present them a cert authorization when they are
> auth'ing.  So I can even use the current certs I have in place now?

These are for all client connections that use STARTTLS, not just MUAs.
The difference is that MTAs typically don't quit if they can't verify
the cert (check it against a root certificate store), so using a
self-signed cert is adequate.

It is increasingly harder to support MUAs with noncommercial certs,
however. You can get basic ones fairly cheaply, so I recommend it to
avoid annoying warnings to your users.

>> # client TLS parameters, forward mail via TLS if possible
>> smtp_tls_security_level = may
> 
> I had this one already I believe.

This is what you need for your server to connect *as a client* to other
MTAs, opportunistically using STARTTLS when offered.

> The wrapper mode is probably a Outlook issue, or at least an older buggy
> MUA client issue?  I do not have any easy access to Outlook.  How do you
> go about testing before deployment?

Don't set it up until you have everything else working properly (TLS,
submission, etc.). Then wait until you find a need for it. Normally, the
 Postfix defaults in master.cf will suffice (assuming your distribution
hasn't fiddled with them).

> smtp_tls_cert_file   = /opt/local/etc/ssl/certs/dovecot.pem
> smtp_tls_key_file= /opt/local/etc/ssl/private/dovecot.pem

Remove.

> smtp_tls_security_level  = may

Keep.

> smtp_tls_session_cache_database  =
> btree:$data_directory/smtp_tls_session_cache

Keep if you need it.

> smtpd_sasl_security_options  = noanonymous

Change to noanonymous, noplaintext if you don't want passwords sent in
the clear.

> smtpd_tls_ask_ccert  = yes

Why?

> smtpd_tls_ce

Re: Suggestions on submission port config

[Victor Duchovni]

On Fri, May 01, 2009 at 10:19:40AM -0400, Jorey Bump wrote:

> > My end goal here is to get this all working, and then change these ports
> > to, for example, 25 -> 2525 and 587 -> 587587 unless there is some other
> > convention.  I am going to put a anti spam proxy in front of all this.
> 

There is no port "587587", the TCP port range (over both IPv4 and IPv6) is
from 0 to 65535, but "0" means "unspecified" at the socket API level. In
any case 587587 is usually equivalent to its residue mod 2^16 which is
63299, not a good port to choose for a service (dynamic port range on
most systems).

-- 
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:


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.

Re: Suggestions on submission port config

[Jorey Bump]

Victor Duchovni wrote, at 05/01/2009 10:26 AM:
> On Fri, May 01, 2009 at 10:19:40AM -0400, Jorey Bump wrote:

FTR: No, I didn't! :)

>>> My end goal here is to get this all working, and then change these ports
>>> to, for example, 25 -> 2525 and 587 -> 587587 unless there is some other
>>> convention.  I am going to put a anti spam proxy in front of all this.
> 
> There is no port "587587", the TCP port range (over both IPv4 and IPv6) is
> from 0 to 65535, but "0" means "unspecified" at the socket API level. In
> any case 587587 is usually equivalent to its residue mod 2^16 which is
> 63299, not a good port to choose for a service (dynamic port range on
> most systems).

Re: Sender based outgoing IP selection

[mouss]

Attila Nagy a écrit :
> Hello,
> 
> I have to route e-mails coming from different IP addresses to the world
> (no single smarthost, the target can be anything) with different source
> IPs.
> 
> So a mail coming in on 1.1.1.1 should go out with the source address of
> 2.2.2.2 and another coming in on 3.3.3.3 should go out from 4.4.4.4.
> Postfix listens on 1.1.1.1 and 3.3.3.3 and the machine has also the
> addresses of 2.2.2.2 and 4.4.4.4 of course.
> 
> Am I right when I think this can only be done correctly with two postfix
> instances?
> 

you need multiple instances, one for each "routing configuration". so
you need one for 1.1.1.1, another for 2.2.2.2 and so on.

Re: Transport Maps Ignored After Upgrade

[Eric Cunningham]

I think I've found a/the fix for re-enabling the original behavior of my 
transport maps and MX relaying.  I added .$mydomain to mydestination in 
main.cf.  This is in addition to $mydomain which was already in 
mydestination.


$mydomain vs. .$mydomain is subtle but apparently important.

Re: Transport Maps Ignored After Upgrade

[Victor Duchovni]

On Fri, May 01, 2009 at 01:54:03PM -0400, Eric Cunningham wrote:

> I think I've found a/the fix for re-enabling the original behavior of my 
> transport maps and MX relaying.  I added .$mydomain to mydestination in 
> main.cf.  This is in addition to $mydomain which was already in 
> mydestination.
>
> $mydomain vs. .$mydomain is subtle but apparently important.

Postfix will never search for ".example.com" domains in the
$mydestination list, so this change has no effect. Perhaps in making
this change you also triggered other changes that solved the problem.

Now, in fact, if you don't set "relay_domains" explicitly, as a matter
of regrettable backwards compatibility requirements, the value of
$relay_domains defaults to to "$mydestination" and in the context of
"$relay_domains", ".example.com" keys do come into play given an
appropriate setting of parent_domain_matches_subdomains.

The right solution is to set relay_domains explicitly and correctly,
rather than rely on side-effects from $mydestination.

Secondly, it appears that you have changed the default value of
parent_domain_matches_subdomains. You should review this parameter
and make sure you understand its impact.

-- 
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:


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.

[no subject]

[Len Conrad]

postmap -q "67.218.188" 
mysql:/usr/local/etc/postfix/mysql-mta_clients_reactive_b.cf
 554 mta_client_reactive_b

postmap -q "67.218.188.4" 
mysql:/usr/local/etc/postfix/mysql-mta_clients_reactive_b.cf
... no data

man 5 access  seems to make no distinction between .map and SQL tables:

HOST NAME/ADDRESS PATTERNS

With lookups from indexed files such as DB or DBM,  or  from  networked
tables  such  as  NIS,  LDAP  or SQL, the following lookup patterns are
examined in the order as listed

Subnetworks  are  matched  by  repeatedly  truncating  the  last
".octet"  from the remote IPv4 host address string until a match
is found in the access table, or until further truncation is not
possible.

Len

Re: your mail

[Ralf Hildebrandt]

* Len Conrad :
> postmap -q "67.218.188" 
> mysql:/usr/local/etc/postfix/mysql-mta_clients_reactive_b.cf
>  554 mta_client_reactive_b
> 
> postmap -q "67.218.188.4" 
> mysql:/usr/local/etc/postfix/mysql-mta_clients_reactive_b.cf
> ... no data
> 
> man 5 access  seems to make no distinction between .map and SQL tables:
> 
> HOST NAME/ADDRESS PATTERNS
> 
> With lookups from indexed files such as DB or DBM,  or  from  networked
> tables  such  as  NIS,  LDAP  or SQL, the following lookup patterns are
> examined in the order as listed
> 
> Subnetworks  are  matched  by  repeatedly  truncating  the  last
> ".octet"  from the remote IPv4 host address string until a match
> is found in the access table, or until further truncation is not
> possible.

So where is the problem now?

-- 
Ralf Hildebrandt
Postfix - Einrichtung, Betrieb und Wartung   Tel. +49 (0)30-450 570-155
http://www.computerbeschimpfung.de
"How would you rate our government's incompetence?
Typical unix response:   Unmatched ".

Re: your mail

[Len Conrad]

-- Original Message --
From: Ralf Hildebrandt 
Reply-To: postfix-users@postfix.org
Date:  Fri, 1 May 2009 20:56:15 +0200

>* Len Conrad :
>> postmap -q "67.218.188" 
>> mysql:/usr/local/etc/postfix/mysql-mta_clients_reactive_b.cf
>>  554 mta_client_reactive_b
>> 
>> postmap -q "67.218.188.4" 
>> mysql:/usr/local/etc/postfix/mysql-mta_clients_reactive_b.cf
>> ... no data
>> 
>> man 5 access  seems to make no distinction between .map and SQL tables:
>> 
>> HOST NAME/ADDRESS PATTERNS
>> 
>> With lookups from indexed files such as DB or DBM,  or  from  networked
>> tables  such  as  NIS,  LDAP  or SQL, the following lookup patterns are
>> examined in the order as listed
>> 
>> Subnetworks  are  matched  by  repeatedly  truncating  the  last
>> ".octet"  from the remote IPv4 host address string until a match
>> is found in the access table, or until further truncation is not
>> possible.
>
>So where is the problem now?

1. my email client discarded my wonderful Subject: line

2. The problem is that a query for 67.218.188.4 is not matched by an entry of 
67.218.188.  This works in hash:.map tables, so why doesn't it work in SQL 
tables?   iow, how to block a Class C with SQL table?

Len

Re: your mail

[Noel Jones]

Len Conrad wrote:

postmap -q "67.218.188" 
mysql:/usr/local/etc/postfix/mysql-mta_clients_reactive_b.cf
 554 mta_client_reactive_b

postmap -q "67.218.188.4" 
mysql:/usr/local/etc/postfix/mysql-mta_clients_reactive_b.cf
... no data

man 5 access  seems to make no distinction between .map and SQL tables:

HOST NAME/ADDRESS PATTERNS

With lookups from indexed files such as DB or DBM,  or  from  networked
tables  such  as  NIS,  LDAP  or SQL, the following lookup patterns are
examined in the order as listed

Subnetworks  are  matched  by  repeatedly  truncating  the  last
".octet"  from the remote IPv4 host address string until a match
is found in the access table, or until further truncation is not
possible.

Len




You appear to have a question about the table search order... 
If that's not the case, please correct me.


The access man page describes how a map is searched when it's 
used as an access table.


postmap -q does not have a search order, it only performs the 
lookup specified.


  -- Noel Jones

Re: your mail

[Ralf Hildebrandt]

* Len Conrad :

> 1. my email client discarded my wonderful Subject: line

Your client is Imail? Their servers are crap so why should the client
be better :)
 
> 2. The problem is that a query for 67.218.188.4 is not matched by an
> entry of 67.218.188.  This works in hash:.map tables, so why doesn't it
> work in SQL tables?  iow, how to block a Class C with SQL table?

It works just the same

Postfix performs the lookups:

67.218.188.4
67.218.188
67.218
67

against the map. Try query logging.

-- 
Ralf Hildebrandt
Postfix - Einrichtung, Betrieb und Wartung   Tel. +49 (0)30-450 570-155
http://www.computerbeschimpfung.de
Next thing you know, someone will nail 95 patches to the door, then
register postfixreformation.org. Hmmm, no, on further thought,
religious zeal is better suited to other MTA's anyway. As are the 95
patches.

Re: Suggestions on submission port config

[Scott Haneda]

On May 1, 2009, at 6:30 AM, Jorey Bump wrote:

Scott Haneda wrote, at 04/30/2009 10:31 PM:>

On Apr 24, 2009, at 9:43 PM, Jorey Bump wrote:


Since one of the purposes of the submission port is to support road
warriors, I feel it should be as secure as possible and the entire
communication should be encrypted.


I am in a bad spot in this regard, because of some of the faults of  
my
current email server.  It is pushed a bit to move users to 587, but  
the

server does not support SSL/TLS.  It would be very hard for me to get
them to all change their settings to use SSL/TLS.  I would love to  
make
587 the default secure port, I just do not thing I can put my users  
in

that situation.

If postfix can log in a way that I can tell what is going on, and  
over

time, I can make a call a day, and convert people over to TLS,
eventually I will flip this switch.


You can alter the name syslog uses for the submission service by  
adding:


 -o syslog_name=postfix-submission


Nice, thanks.


Well, that's another potential advantage of using port 587: you can
spare authenticated users (and your system) from filter/proxy scans.


Glad you pointed that out, slipped my mind, but that is probably the  
most compelling reason to get all users to port 587 for me at least.



Note that some environments still want to scan outgoing mail. Once
again, the fact that you're using an alternate port allows you to
customize settings to suit the purpose, so it can be another win.


Indeed, great point.

It's up to you. I use SMTP AUTH for webmail, partly because it  
provides

better logging for troubleshooting.


Good point.  What webmail are you using?  Does it globally SMTP  
AUTH via

a config file and a smtp account, or is each user login it's own SMTP
AUTH case, which is where you are picking up the logging data  
specific

to the sender under that specific account?


I use SquirrelMail, which uses individual login credentials for both
IMAP access and SMTP AUTH. It's nice to have the user information in  
the
logs. In fact, if you are using Roundcube, make sure it's fully  
patched.

There is a vulnerability that is still being probed for daily against
likely locations for it on web servers.


Thanks for the heads up, I will make sure I am patched.  I have been  
using SM for years now, I just find it is too slow, and even with some  
skins, is not what my users are after.  I have a feeling the slowness  
will be a non issues once I get dovecot talking to it.  However, my  
users rarely care about what is under the hood, and eat with their eyes.


A friend of mine signed up for some cheapo hosting account, and  
they had
a apple script to set it up.  It did not work, but I have been  
meaning
to swipe it and fix it.  It looks very simple to deal with, and you  
can
shove the users login name in, so all they do is run it, connect to  
get
email, enter in their password, and click "remember" and they are  
done.


I would bet I can alter the default port in this script as well.


That's one option, but you might be better off going with the
autoconfiguration and providing instructions where that fails. Asking
users to run scripts is sending the wrong message, IMHO. It just makes
them more vulnerable to phishing and other exploits that rely on bad
practice.


I hear ya.  Auto configuration is something Apple Mail only seems to  
do.  I have never seen it in other apps, though I have only personally  
used Entourage.  I use Thunderbird in testing now, and I do not see  
any really slick auto conf in there either.


Let me put it this way, many times, my users can not enter in their  
own email address, or will enter in a host name as m...@example.com  
over mail.example.com, I know right away when I tell them to "get  
mail" and do not see the connection come in.


I have learned the common mistakes they make, but even a auto  
configuration still requires some data entry on their part.  What I  
would prefer is a simple xml or text file, that I could tell them to  
import into a mail app, this could be universal, and have all the  
settings in it, sans a password.



When it comes to a TLS or even an SSL connection, I take it at that
point, the AUTH mechanism you chose really makes no difference?  Is
there a performance hit, where it would be more ideal to use a less
complex mechanism since you are TLS'ing the entire channel anyway?


Absolutely. Enforced TLS with PLAIN/LOGIN is often the best all-around
solution (total message encryption, low overhead authentication
mechanism). In that case, you can target TLS if you need to throw more
resources at it (increase entropy for the PRNG, hardware encryption,  
etc.).



Thanks, makes good sense.
--
Scott * If you contact me off list replace talklists@ with scott@ *

Re: Suggestions on submission port config

[Scott Haneda]

On May 1, 2009, at 7:19 AM, Jorey Bump wrote:

Scott Haneda wrote, at 04/30/2009 10:11 PM:


What happens is, under heavy MTA load on port 25, I will run out of
connection slots on port 25.


Have you investigated the nature of this problem?


Thoroughly. My current email server lacks control, it is only recently  
we have even been given greylisting.  Moving users to port 587 largely  
solved it, but issues still remain.  It is just time for me to move  
on.  I am at the whim of the developer, this is not a config file  
driven email server.  Even mention of SPF on his mail list get you  
told to not talk about it.  It is not an option, and while I  
personally do not intend to use SPF, I want options, which postfix has  
abound.


To be honest, I have received more education and support from you and  
a few other people on this list in a few days than the 10 years of  
using something else.


I do thank you all again, as well as those who make postfix what it is.


By moving users to 587, I do not care
about port 25 connection slots.  MTA's will try again later if busy.


You might be chasing a red herring. If your server is overloaded,  
there
is a reason why, and there may be more effective remediation  
techniques

available. Improving your submission service is good, but it might not
deliver the performance payoff you're expecting.


You nailed it, there are indeed many more techniques for dealing with  
my issues.  Manually scanning logs and putting IP ranges into a local  
DNS blacklist and manually creating rules that are not flexible in how  
they can match patterns is what hinders me for the most part.



What do you guys think?

My end goal here is to get this all working, and then change these  
ports
to, for example, 25 -> 2525 and 587 -> 587587 unless there is some  
other
convention.  I am going to put a anti spam proxy in front of all  
this.


If you still have a heavy load, consider separating your MX entirely
from submission, using separate instances/machines. It's generally
easier to move the MX, since MUA configurations don't care about it.


I have this as a option from the beginning of setup.  I was given a  
large enough IP allocation that I tend to give up an IP for each  
service, and create DNS records pointing to each IP.  If I ever need  
to for example, most SMTP 587 to it's own machine, it is as simple as  
just setting up the software, remove the old IP from the old machine,  
and putting it into the new machine.


I use will use this when I migrate as well, not having to fiddle with  
DNS TTL's and some other ISP's that seem to cache DNS and not honor  
TTL's then becomes a non issue.


I just do not want to add too much to my learning curve, so first,  
get

postfix to where I understand it, then toggle the ports and put the
proxy in.  It should blindly pass the traffic, I assume in much the  
same

way stunnel does.

I am open to any and all advice on this matter to make this work  
best.

I have a feeling later on down the road I will need to learn exactly
what things to disable in postfix, as it should not do any bouncing  
at
all, anything that will lead to backsplatter, since I am putting a  
proxy

ahead of it.


FWIW, a poorly implemented proxy can do more harm than good. A lot of
sites just toss them in, and don't pay attention to finer details like
DNS settings and recipient validation.


I have spent the past few years looking at them and reading about  
them.  Starting with the hardware driven devices like Barracuda.  My  
main reason for not deploying as of yet was the only way to get user  
validation on my server was LDAP, which I could not ever get to work  
reliably.  Maintaining a text file of users was an option, but at  
minutes to dump a list of users via AppleScript from the email server,  
I did not like that option.


I am settling in on ASSP, which seems to solve my needs, and provide  
everything I need.  If it turns out I do not like it, the nice thing  
about a proxy is, you just turn it off, a quick change of port  
listeners in postfix, and I should be back up and running.



# server TLS parameters
smtpd_tls_key_file = /etc/ssl/yoshino.meidokon.net_key
smtpd_tls_cert_file = /etc/ssl/yoshino.meidokon.net_crt
smtpd_tls_auth_only = yes  <-- as mentioned, user can only auth on a
secure connection
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes


You have the two cert, ahhh, smtp*d*.  Ok, I think I get it, that  
is for

MUA traffic, and you present them a cert authorization when they are
auth'ing.  So I can even use the current certs I have in place now?


These are for all client connections that use STARTTLS, not just MUAs.
The difference is that MTAs typically don't quit if they can't verify
the cert (check it against a root certificate store), so using a
self-signed cert is adequate.

It is increasingly harder to support MUAs with noncommercial certs,
however. You can get basic ones fairly cheaply, so I recommend it to
avoid annoying 

Re: Suggestions on submission port config

[Jorey Bump]

Scott Haneda wrote, at 05/01/2009 08:37 PM:
> On May 1, 2009, at 7:19 AM, Jorey Bump wrote:
>>
>> The difference is that MTAs typically don't quit if they can't verify
>> the cert (check it against a root certificate store), so using a
>> self-signed cert is adequate.
>>
 # client TLS parameters, forward mail via TLS if possible
 smtp_tls_security_level = may
>>>
>>> I had this one already I believe.
>>
>> This is what you need for your server to connect *as a client* to other
>> MTAs, opportunistically using STARTTLS when offered.
> 
> In a previous sentence you used the word 'typically' in regards to if
> the MTA will quit or not on seeing a cert.  What is the risk here?

Most connecting MTAs will still encrypt the communication if they cannot
*verify* the certificate, so there is little risk of sniffing on the
wire. Some policies will require verification, but that usually implies
a special relationship.

> If I
> understand, this gives an opportunistic ability for MTA to MTA
> discussion to be secure, falling back on the old plain method if it is
> not available.

Correct.

> Is there really a lot of exploiting going on in-between one MTA and
> another?  From what I can tell, this would boil down to a rogue person
> at some router between me and say, gmails servers, that wanted to
> intercept traffic.  Just does not seem likely.

Which is why most MX hosts and relays use encryption opportunistically
instead of enforcing it. Perhaps the days are numbered even for this
innocent approach...

>>> smtpd_sasl_security_options  = noanonymous
>>
>> Change to noanonymous, noplaintext if you don't want passwords sent in
>> the clear.
> 
> If I set this to noanonymous, noplaintext to confirm, if any of my
> current users are using an authenticated plain text login method, they
> would fail to login?

In many cases, yes, because plaintext mechanisms won't even be offered
unless the channel is encrypted. However, some clients might
automatically use the remaining secure mechanisms that are still offered.

> This then gets my phone ringing, where I can help them make the changes
> to either use a non plain text login method, with auth, or use a plain
> style login with crypto.  I think I have that correct.

Yes.

>>> submission inet  n - n -
>>> - smtpd
>>> -o smtpd_tls_security_level=may
>>> -o smtpd_tls_auth_only=no
>>> -o smtpd_sasl_auth_enable=yes
>>> -o smtpd_client_restrictions=permit_sasl_authenticated
>>
>> IMHO, too weak for port 587.
> 
> Can we explore your HO on this.  I have helped many a friend set up
> email for any number of the 9.99 a month ISP's out there, the are all
> offering normal 25, some alt submission port, and some SSL port as
> well.  I am yet to see any particular mandate that the submission port
> be crypto mandated.  Not that I want to just follow the examples set by
> others, as often is the case, they are "doing it wrong" anyway.
> 
> I am just not seeing why a user can not auth with no crypto.  Or, are
> you taking the stance that users really do not know about this stuff,
> and it would be best if you protect their actions on their behalf?

No, I'm more interested in protecting the integrity of the submission
service on port 587, and prefer to see it locked down as tightly as
possible. The main reason is to prevent a breakdown in security that
could lead ISPs to block port 587 as many have done with port 25. I've
seen misguided configurations that duplicate port 25 settings on port
587, making the port a fully functioning MX that can be abused by spammers.

Another reason is that some hotels and internet cafes arrogantly try to
proxy email connections, and that's a lot more threatening than
unencrypted MTA to MTA communication. TLS helps mitigate this, as it is
really hard to proxy encrypted connections without generating a warning
(unless they trick you into installing a root certificate in your client).

> I certainly can appreciate that.  Having to deal with hundreds of iPhone
> users, and desktop users, when I toggle this switch may prove less than
> fun.  Since my old server does not support SSL/TLS, it is not like I can
> send an email out, tell them to switch, and then mass move everyone to
> postfix.  This is going to be a throw the switch, and start answering
> phone calls.
> 
> I do really like the idea of all users being secure.  Perhaps I will set
> up a new MX, run the old and the new at the same time, and migrate one
> domain at a time, that would remove the "throw the switch" support burden.
> 
> Not really liking the idea of using a new domain for setting up the
> postifx server.  I am pretty sure I can not do this in the same domain,
> as the second I add in a MX pointing to the new postfix server, that is
> going to break everything.

You have your work cut out for you.

> What specifically about smtps was it that you ended up determining you
> needed it?

I needed to support legacy clients. I don