Re: LoadShared Failover

[Michael Maymann]

Hi,

Stan: My question is not how I setup the solution, but how I *BEST* (best
practice) setup the loadshared/failover postfix solution I described
earlier.
If there isn't a nice howto already, I guess I can figure this out myself -
bonding is easy, if this is the prefered solution for a postfix install
like mine - but if it is: how do you cope with the question I asked earlier:
- How do I solve client<->server communication, when requests will not get
answered from same IP - or can it be - and if so: how do I do this, is
there a how-to on setting this up on RHEL6 ?

Would just like to hear the lists opinion before going in any specific
direction, and figuring out that was the wrong one...:) !


Best regards
~maymann


2012/3/12 Stan Hoeppner 

> On 3/10/2012 8:30 AM, Michael Maymann wrote:
>
> > How do I best setup a loadshared failover postfix mailrelay solution for
> > this on RHEL6 ?
>
> You consult the RHEL6 documentation.  If you don't find the answer
> there, you contact Red Hat support who will point you in the right
> direction.  Isn't this why you use a paid commercial Linux distro?
>
> --
> Stan
>
>

Re: Header Checks question

[Ralf Hildebrandt]

* Selcuk Yazar :
> Hi,
> 
> We have a rule on header checks file like this;
> 
> /^Subject:.*sex/  REJECT  "Bad Header 92"
> 
> but last week our staff sen an email an it's subject is
> 
> Subject: =?utf-8?B?QsSwWSBNRVNMRUsgRVTEsMSexLAgSEFGVEEgNQ==
> 
> thats why this mail rejected ? becouse of its contains Sex word :)
> 
> what is the  method correct this problem

Improve the header checks
e.g. by requiring a word boundary-

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | http://www.charite.de

Re: Header Checks question

[Victoriano Giralt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/12/2012 09:26 AM, Ralf Hildebrandt wrote:
> Improve the header checks e.g. by requiring a word boundary-
Although I agree, as encoded headers are becoming common place
nowadays, decoding would be a nice enhancement to the header checking
code.

Question is, will the decoding libraries increase the attack surface?
Is it worth?

- -- 
Victoriano Giralt  Central ICT Services
Systems ManagerUniversity of Malaga
+34952131415   SPAIN
===
A: Yes.
> Q: Are you sure ?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email ?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFPXbZqV6+mDjj1PTgRAiaEAJ92hiO29t3hPxDTHaECcmA7Cj1WNwCgis/y
o1JygX1cbKKgz1IqK5TN43c=
=z8i3
-END PGP SIGNATURE-

Re: LoadShared Failover

[Stan Hoeppner]

On 3/12/2012 2:28 AM, Michael Maymann wrote:
> Hi,
> 
> Stan: My question is not how I setup the solution, but how I *BEST* (best
> practice) setup the loadshared/failover postfix solution I described
> earlier.

I dunno if there is a BCP covering smtp submission/relay server load
balancing/fail over.  I'd make an educated guess that just about
everyone with more than one submission/relay server is using round robin
DNS.

> If there isn't a nice howto already, I guess I can figure this out myself -

There are many.  You can Google faster than I can point you to lmgtfy.
I'd have thought you'd have already done so...

> bonding is easy, if this is the prefered solution for a postfix install

What kind of bonding are you referring to here?

> like mine - but if it is: how do you cope with the question I asked earlier:

"Like yours"?  You have two outbound submission/relay servers, correct?
 Nothing unique here.

> - How do I solve client<->server communication, when requests will not get
> answered from same IP - or can it be - and if so: how do I do this, is

You're over thinking this.

> there a how-to on setting this up on RHEL6 ?

My point was that you've already paid for support.  Simply call and ask
RHEL support the question you're asking here.  Surely they'd point you
in the right direction.

> Would just like to hear the lists opinion before going in any specific
> direction, and figuring out that was the wrong one...:) !

This question doesn't come up very often.  When it does the OP is
working at scale (think dozens of relays) and he's after parallel
performance optimization, not simple fail over redundancy.  The
extremely low frequency of this question should tell you something about
the solution people are using, and the level of difficulty required to
implement it.  I.e. this requirement is mundane, has been around
forever, as has the solution, which is round robin DNS.

-- 
Stan

Strange error about bounce.cf template

[Charles Marcus]

Hi all,

I am getting the following error whenever a bounce is generated:

Mar 12 06:20:59 myhost postfix/bounce[24765]: warning: 
/etc/postfix/bounce.cf, line 108: missing "e mail system?" end marker


I have attached my /etc/postfix/bounce.cf file... can anyone see a 
problem with it?


My system rarely generates bounces so I don't know how long this has 
been going on, but I just switched to postini and am having a problem 
with forwarding which is now resulting in bounces for the few accounts 
we have set up to forward all inbound mail to an external account, so I 
happened to see this in the logs...


Thanks,

--

Best regards,

Charles
#
# The failure template is used when mail is returned to the sender;
# either the destination rejected the message, or the destination
# could not be reached before the message expired in the queue.
#

failure_template = <

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

   The mail system
EOF


#
# The delay template is used when mail is delayed. Note a neat trick:
# the default template displays the delay_warning_time value as hours
# by appending the _hours suffix to the parameter name; it displays
# the maximal_queue_lifetime value as days by appending the _days
# suffix.
#
# Other suffixes are: _seconds, _minutes, _weeks. There are no other
# main.cf parameters that have this special behavior.
#
# You need to adjust these suffixes (and the surrounding text) if
# you have very different settings for these time parameters.
#

delay_template = <

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

   The mail system
EOF


#
# The success template is used when mail is delivered to mailbox,
# when an alias or list is expanded, or when mail is delivered to a
# system that does not announce DSN support. It is an error to specify
# a Postmaster-Subject: here.
#

success_template = <

Re: Header Checks question

[Larry Stone]

On Mar 12, 2012, at 3:14 AM, Selcuk Yazar wrote:

> Hi,
> 
> We have a rule on header checks file like this;
> 
> /^Subject:.*sex/  REJECT  "Bad Header 92"
> 
> but last week our staff sen an email an it's subject is
> 
> Subject: =?utf-8?B?QsSwWSBNRVNMRUsgRVTEsMSexLAgSEFGVEEgNQ==
> 
> thats why this mail rejected ? becouse of its contains Sex word :)
> 

I'd suggest you put some more thought into this and why you want to reject all 
mail with the letters sex in the subject. Besides encoded subjects, there are 
lots of legitimate words (particularly place names) that contain sex (just off 
the top of my head, as a former New Jersey, USA resident, there are three 
counties ending in sex: Essex, Middlesex, and Sussex; lots more elsewhere in 
the world). Your check will reject legitimate mail that contains the names of 
these places.

-- 
Larry Stone
lston...@stonejongleux.com
http://www.stonejongleux.com/

Re: Header Checks question

[Selcuk Yazar]

we are turks and we hate sex word :P

thank you all.

selcuk.

On Mon, Mar 12, 2012 at 1:41 PM, Larry Stone wrote:

>
> On Mar 12, 2012, at 3:14 AM, Selcuk Yazar wrote:
>
> > Hi,
> >
> > We have a rule on header checks file like this;
> >
> > /^Subject:.*sex/  REJECT  "Bad Header 92"
> >
> > but last week our staff sen an email an it's subject is
> >
> > Subject: =
> >
> > thats why this mail rejected ? becouse of its contains Sex word :)
> >
>
> I'd suggest you put some more thought into this and why you want to reject
> all mail with the letters sex in the subject. Besides encoded subjects,
> there are lots of legitimate words (particularly place names) that contain
> sex (just off the top of my head, as a former New Jersey, USA resident,
> there are three counties ending in sex: Essex, Middlesex, and Sussex; lots
> more elsewhere in the world). Your check will reject legitimate mail that
> contains the names of these places.
>
> --
> Larry Stone
> lston...@stonejongleux.com
> http://www.stonejongleux.com/
>
>
>
>


-- 
Selçuk YAZAR
http://www.selcukyazar.blogspot.com

Use a Spam gateway server

[Thierry Fougera]

Hi All Postfix Users,

I've one question with one advanced Postfix configuration.

My architecture:
2 Frontal Server MX01 (Prio 10) and MX02 (Prio 20) with Postfix and Dovecot.
1 Backend Server FILTERGW with Postfix and SpamAssassin and Amavis.

When one mail come to MX01, I check with MySQL if the recipient would scan spam 
& virus, juste scan virus or no scan.
If the recipient would just virus, the mail it's relayed to FILTERGW on a 
specific port with a content_filter to Amavis.
Same if the recipient would no virus and no spam scan, the mail it's relayed to 
FILTERGW on a specific port for Amavis who I disable the scann.

For this 2 version that work really good, my problem it's just if the customer 
would the SPAM scan.
If the recipient would spam I force virus scan.

MX01 relay the mail to the port 10027 (FILTERGW), on this port I've (in the 
master.cf):
10027   inet            n               -               n               -       
        -               smtpd
                -o content_filter=spamassassin
                -o disable_dns_lookups=yes
                -o smtp_send_xforward_command=yes
                -o smtp_bind_address=10.8.1.6
                -o smtpd_recipient_restrictions=permit_mynetworks,reject
                -o mynetworks=10.8.1.3,10.8.1.4,10.8.1.6,127.0.0.1
                -o 
receive_override_options=no_unknown_recipient_checks,no_header_body_checks
                -o local_recipient_maps=
                -o relay_recipient_maps=
                -o smtpd_sender_restrictions=
                -o smtpd_helo_restrictions=
                -o smtpd_client_restrictions=
                -o smtpd_restriction_classes=

spamassassin    unix            -               n               n               
-               -               pipe
                flags=Rq user=vmail argv=/usr/bin/spamc -u ${user}@${nexthop} 
-e /usr/sbin/sendmail -oi -f ${sender} ${recipient}

The mail enter on the 10027 and it's scanned by SpamAssassin, but after I've my 
problem ...
SpamAssassin give again the mail to FILTERGW after the scan, but FILTERGW send 
the mail to MX01 (prio 10 in the MX record) and ... One Loop start ...

My wish it's, after the "spamassassin" process, I would that the mail it's 
relayed to "antivirusseul:[127.0.0.1]:10032".

At the moment, I've add this line in the main.cf
transport_maps = hash:/etc/postfix/spamassast

In the spamassast I've
* smtp:[127.0.0.1]:10032

This process work, when SpamAssassin have finish the scan, they give again the 
mail to postfix, and posfix force the transport to Amavis Port.
Amavis make the scan for virus, and after they send the mail to MX02 who 
Dovecot save the mail.

I would make that more clean, and since 2 weeks I search a issue for not using 
"transport_maps" because all locale mail that I would send from FILTERGW (ex 
with the "mail" command) are send to the transport_maps ...
I would not use SpamAssassin into Amavis ;) I would it's possible use only the 
master.cf

Sorry for this long mail, but I've think it's better if I explain the request 
correctly.

Thank a lot all for you suggestion and your help.

Thierry Fougera


-- My main.cf config --
root@filtergw:/etc/postfix# cat main.cf

# CONFIGURATION DES CHEMINS DE POSTFIX #

queue_directory = /var/spool/postfix
command_directory = /usr/sbin
daemon_directory = /usr/lib/postfix
data_directory = /var/lib/postfix
sendmail_path = /usr/sbin/sendmail
newaliases_path = /usr/bin/newaliases
mailq_path = /usr/bin/mailq

###
# CONFIGURATION DU RESEAU #
###
myhostname = filtergw.adv.local
mydomain = adv.local
myorigin = filtergw.adv.local
mynetworks_style = host
mynetworks = 127.0.0.1, 10.8.1.3, 10.8.1.4, 10.8.1.6
transport_maps = hash:/etc/postfix/spamassast

#
# CONFIGURATION AVANCEE POSTFIX #
#
smtpd_banner = $myhostname ESMTP $mail_name
mail_owner = postfix
unknown_local_recipient_reject_code = 550
debug_peer_level = 2
debugger_command =
         PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
         ddd $daemon_directory/$process_name $process_id & sleep 5
setgid_group = postdrop
message_size_limit = 204800
mailbox_size_limit = 204800
soft_bounce = yes
dspam_destination_recipient_limit = 1
smtpd_helo_restrictions = permit_mynetworks,reject
readme_directory = /usr/share/doc/postfix
html_directory = /usr/share/doc/postfix/html

Re: Strange error about bounce.cf template

[Wietse Venema]

Charles Marcus:
> Hi all,
> 
> I am getting the following error whenever a bounce is generated:
> 
> Mar 12 06:20:59 myhost postfix/bounce[24765]: warning: 
> /etc/postfix/bounce.cf, line 108: missing "e mail system?" end marker
> 
> I have attached my /etc/postfix/bounce.cf file... can anyone see a 
> problem with it?

No warnings are logged here. Perhaps your bounce.cf file contains
carriage-returns or other junk that got removed when you attached 
it to the postfix-users submission.

Wietse

Re: Strange error about bounce.cf template

[Charles Marcus]

On 2012-03-12 9:44 AM, Wietse Venema  wrote:

Charles Marcus:

I am getting the following error whenever a bounce is generated:

Mar 12 06:20:59 myhost postfix/bounce[24765]: warning:
/etc/postfix/bounce.cf, line 108: missing "e mail system?" end marker

I have attached my /etc/postfix/bounce.cf file... can anyone see a
problem with it?



No warnings are logged here. Perhaps your bounce.cf file contains
carriage-returns or other junk that got removed when you attached
it to the postfix-users submission.


Well... I just opened it in notepad++ to check, and I did indeed see 
CRLF at the end of every line (and for the blank lines)... so, if you 
didn't see them in the one that was attached, I guess something stripped 
them out?


Weird... I don't ever recall editing this file with anything other than 
nano, but anyway, after fixing this, indeed, the warning is gone.


Thanks for the cluestick Wietse...

--

Best regards,

Charles

Re: Strange error about bounce.cf template

[Charles Marcus]

On 2012-03-12 10:53 AM, Charles Marcus  wrote:

Well... I just opened it in notepad++ to check, and I did indeed see
CRLF at the end of every line (and for the blank lines)... so, if you
didn't see them in the one that was attached, I guess something stripped
them out?


Out of curiosity, I just saved the attached file from the email and I 
did see the CR characters in it (once I enabled 'show all characters' in 
notepad++), so don't know why you didn't see them (or... can't tell from 
your comment, maybe you didn't actually open it to check)...


Anyway, now worries, its all good now...

--

Best regards,

Charles

Postini as outbound relayhost breaks aliases (and bcc maps) to external addresses...

[Charles Marcus]

I hope someone here who has used Postini can suggest a way to resolve this.

One of my clients just switched from webroot's EMail SaaS (antispam 
service) to Postini, and they do use postini (as they did webroot) for 
outbound relaying/filtering.


This change has broken mail forwarding via aliases for the accounts that 
I had set up to forward all inbound mail to an outside account. Aliases 
pointing to internal accounts continue to work as expected.


It also broke the same thing with my sender_bcc maps when the sender_bcc 
target is an external address...


I get the following error in the logs ( is a valid 
user on our system):


myhost : Mon Mar 12, 06:24:23 : ~
 # less /var/log/messages | grep C0F52760CFF
Mar 12 02:48:29 myhost postfix-25/smtpd[25932]: C0F52760CFF: 
client=exprod6mx207.postini.com[64.18.1.107]
Mar 12 02:48:30 myhost postfix/cleanup[25937]: C0F52760CFF: 
message-id=<1316900478.1331534907972.JavaMail.SYSTEM@sj-w-06cmp78>
Mar 12 02:48:30 myhost postfix/qmgr[20957]: C0F52760CFF: 
from=, size=13599, nrcpt=2 (queue active)
Mar 12 02:48:30 myhost postfix/virtual[25940]: C0F52760CFF: 
to=, relay=virtual, delay=0.67, 
delays=0.65/0.01/0/0.01, dsn=2.0.0, status=sent (delivered to maildir)
Mar 12 02:48:30 myhost postfix/smtp[25939]: C0F52760CFF: 
to=, 
orig_to=, 
relay=outbounds6.obsmtp.com[64.18.5.12]:25, delay=1, 
delays=0.65/0.01/0.27/0.07, dsn=5.0.0, status=bounced (host 
outbounds6.obsmtp.com[64.18.5.12] said: 518 Sender not authorized from 
this ip - psmtp (in reply to MAIL FROM command))
Mar 12 02:48:30 myhost postfix/bounce[25942]: C0F52760CFF: sender 
non-delivery notification: C12549589EE

Mar 12 02:48:30 myhost postfix/qmgr[20957]: C0F52760CFF: removed
myhost : Mon Mar 12, 06:25:09 : ~
 #

I think that somehow postini is *interpreting* the aliased *recipient* 
address as the *sender*, because this user has no trouble sending 
messages directly/normally, and more importantly, because of this text 
in the actual bounce that the sender got:


 (expanded from 
): host outbounds6.obsmtp.com[64.18.5.12] 
said: 518 Sender not authorized from this ip - psmtp (in reply to MAIL 
FROM command)


Note the 'expanded from...'

Has anyone ever dealt with postini using them for outbound 
relay/filtering and aliases pointing to external addresses, or otherwise 
have any insights how I might be able to fix this on my end? Or is my 
only hope to do something on postini's side?


Thanks in advance...

--

Best regards,

Charles

Re: Postini as outbound relayhost breaks aliases (and bcc maps) to external addresses...

[Viktor Dukhovni]

On Mon, Mar 12, 2012 at 12:10:30PM -0400, Charles Marcus wrote:

> I hope someone here who has used Postini can suggest a way to resolve this.
> 
> I get the following error in the logs ( is a valid
> user on our system):
> 
> Mar 12 02:48:29 myhost postfix-25/smtpd[25932]: C0F52760CFF:
> client=exprod6mx207.postini.com[64.18.1.107]
> Mar 12 02:48:30 myhost postfix/cleanup[25937]: C0F52760CFF:
> message-id=<1316900478.1331534907972.JavaMail.SYSTEM@sj-w-06cmp78>
> Mar 12 02:48:30 myhost postfix/qmgr[20957]: C0F52760CFF:
> from=, size=13599, nrcpt=2 (queue active)

This sender address is likely associated with "SPF" records, or
perhaps subject to a simple policy in which email from (envelope)
a domain known to send via Postini is barred from originating from
other sources.

> relay=outbounds6.obsmtp.com[64.18.5.12]:25, delay=1,
> delays=0.65/0.01/0.27/0.07, dsn=5.0.0, status=bounced (host
> outbounds6.obsmtp.com[64.18.5.12] said: 518 Sender not authorized
> from this ip - psmtp (in reply to MAIL FROM command))

There's nothing you can do, don't forward mail to these domains,
they no longer wish to receive such mail.

You are perhaps expected to implement SRS, ... but I would not
bother.

-- 
Viktor.

Re: Postini as outbound relayhost breaks aliases (and bcc maps) to external addresses...

[Noel Jones]

On 3/12/2012 11:10 AM, Charles Marcus wrote:
> I hope someone here who has used Postini can suggest a way to
> resolve this.
> 
> One of my clients just switched from webroot's EMail SaaS (antispam
> service) to Postini, and they do use postini (as they did webroot)
> for outbound relaying/filtering.
> 
> This change has broken mail forwarding via aliases for the accounts
> that I had set up to forward all inbound mail to an outside account.
> Aliases pointing to internal accounts continue to work as expected.
> 
> It also broke the same thing with my sender_bcc maps when the
> sender_bcc target is an external address...
> 
> I get the following error in the logs ( is a valid
> user on our system):
> 
> myhost : Mon Mar 12, 06:24:23 : ~
>  # less /var/log/messages | grep C0F52760CFF
> Mar 12 02:48:29 myhost postfix-25/smtpd[25932]: C0F52760CFF:
> client=exprod6mx207.postini.com[64.18.1.107]
> Mar 12 02:48:30 myhost postfix/cleanup[25937]: C0F52760CFF:
> message-id=<1316900478.1331534907972.JavaMail.SYSTEM@sj-w-06cmp78>
> Mar 12 02:48:30 myhost postfix/qmgr[20957]: C0F52760CFF:
> from=, size=13599, nrcpt=2 (queue active)
> Mar 12 02:48:30 myhost postfix/virtual[25940]: C0F52760CFF:
> to=, relay=virtual, delay=0.67,
> delays=0.65/0.01/0/0.01, dsn=2.0.0, status=sent (delivered to maildir)
> Mar 12 02:48:30 myhost postfix/smtp[25939]: C0F52760CFF:
> to=,
> orig_to=,
> relay=outbounds6.obsmtp.com[64.18.5.12]:25, delay=1,
> delays=0.65/0.01/0.27/0.07, dsn=5.0.0, status=bounced (host
> outbounds6.obsmtp.com[64.18.5.12] said: 518 Sender not authorized
> from this ip - psmtp (in reply to MAIL FROM command))
> Mar 12 02:48:30 myhost postfix/bounce[25942]: C0F52760CFF: sender
> non-delivery notification: C12549589EE
> Mar 12 02:48:30 myhost postfix/qmgr[20957]: C0F52760CFF: removed
> myhost : Mon Mar 12, 06:25:09 : ~
>  #
> 
> I think that somehow postini is *interpreting* the aliased
> *recipient* address as the *sender*, because this user has no
> trouble sending messages directly/normally, and more importantly,
> because of this text in the actual bounce that the sender got:
> 
>  (expanded from
> ): host outbounds6.obsmtp.com[64.18.5.12]
> said: 518 Sender not authorized from this ip - psmtp (in reply to
> MAIL FROM command)
> 
> Note the 'expanded from...'


No, postini is saying n...@external-example.com -- the sender of the
forwarded message -- is not allowed to send mail from your IP.

> Has anyone ever dealt with postini using them for outbound
> relay/filtering and aliases pointing to external addresses, or
> otherwise have any insights how I might be able to fix this on my
> end? Or is my only hope to do something on postini's side?

Best to check with postini about how to handle this.  To handle this
in postfix you would need to rewrite the sender to something in your
domain (aka. SRS), which is rather messy.



  -- Noel Jones

Trouble adding sasl support via dovecot

[Richard Troy]

Hello Folks,

I've been the admin of a site that uses Postfix with Dovecot on RedHat
since, oh, gosh, maybe 1996? It's been a long time. I've never built it
from source, though, just used the rpms (and I wonder if maybe that's my
problem now). It just works, is reliable, and lets me be a very-part-time
administrator.

Repeatedly over the last few years I've been asked to have our mail system
"join the modern age" and provide mail sending capabilities for clients
that aren't on our internal network - via their smart-phones, from home,
etc. OK... Well, way back when the site was set up, smtp servers didn't do
any kind of "auth", but along the way to solving this problem (trying to
configure pop-before-smtp, someone mentioned that Postfix now has an auth
mechanism that uses Dovecot and I should use that instead! Great!  ...
Except that I've spent between 16 and 20 hours on this with no joy, and
while I hate having to ask for help, it's time to ask what things that are
obvious to the less ignorant that I must be doing wrong... Certainly,
given the solid history of Postfix and Dovecot, I must be the problem!

My problem statement is simply, "it should be working", but doesn't, and I
don't get any announcement of "auth" when testing connections to Postfix
as per directions here:

   http://www.postfix.org/SASL_README.html#server_test

At least I haven't broken the normal functionality!

I'm building a new server on the latest Fedora Core (16), but it's lacking
in some hardware and won't be ready for a while, so I'm working with FC
14, running Postfix 2.5.6, and Dovecot 1.2.8. It uses the "cram-md5" auth
scheme (which works fine and I'd hate to change it if I don't have to).
The system has been up and functional on these versions for a couple of
years, and quite stable, we just can't send if we're not local.

When I do "postconf-a" it indicates cyrus and dovecot, so I take it that
means Postfix has been built with sasl support. (I presume this means I
don't have to compile it from source.)

First Dovecot. Its set up to provide all protocols, but only imaps and
pop3s have ports forwarded through the firewall. Plain-text auth is
disabled, ssl is set to yes, ssl_listen is not specified, and the cert and
key files are in the default locations - and work. No cipher list is used.
Dovecot's chrooted. The protocol sections imap and pop3 take ALL the
defaults, as does lda (I've ignored sendmail_path = /usr/lib/sendmail) as
I don't think it matters. "auth default {" has mechanisms set to cram-md5,
digest-md5, plain, and login, with passdb passwd-file pointing to a file
in /etc where the cram data goes. It's not using pam, and there's an OLD
comment in the config:

# Experience says we need an empty passdb - passwd group:

which is followed by passdb passwd{}. Later, there's "userdb passwd {}.

All of that was configured long ago and has been functional.

The changes I've made to add sasl support primarily pertain to the "socket
listen section of "auth default". There, the master section remains
commented out while the client section has been uncommented, the path set
to /var/spool/postfix/private/auth, mode set to 0660, and the user and
group have been set to postfix. ...This is all as described here:

http://www.postfix.org/SASL_README.html
and
http://wiki.dovecot.org/HowTo/PostfixAndDovecotSASL

That's it for Dovecot. Now, to Postfix itself.

>From the working environ, only listening on port 25, I simply added the
following (as per directions already cited above):

smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes
broken_sasl_auth_clients = yes
smtpd_sasl_security_options = noanonymous, noplaintext
smtp_sasl_security_options = noanonymous, noplaintext
smtpd_sasl_tls_security_options = noanonymous
smtp_sasl_tls_security_options = noanonymous

And, of course, permit_sasl_authenticated was added to
smtpd_recipient_restrictions.


I got the impression from the baove sources that Postfix will then use
Dovecot's authentication mechanism via a socket it finds in its
private/auth subdirectory.

NOT documented in any of those places, someone suggested I must turn on
TLS. OK...

The documentation found here:

http://www.postfix.org/TLS_README.html

claims (intimates) that it's not possible to run a site on a self-signed
certificate, however, there's ZERO budget for a signed certificate, so
unless I can get one for ten bucks somewhere, that could be a
deal-breaker here. However, we've been using self-signed certificates for
a while now and wonder why an "exception" mechanism wouldn't exist. As
that web page talks about "Netscape" I suspect it's very old and may no
longer apply.

In any event, I tried this, too (after trying without). On the good side,
an available Android phone, previously reading fine, but unable to send,
no longer complained when the setup was changed to the imap username and
password, same server address, TLS security type, and the server port of
25. HOWEVER, no mail 

How to accept but delete all incoming mail

[Janne H]

Hello.
I've setup a null client (from the postfix doc) to use a sender rewrite with 
sender_canonical_maps to send mail from serv...@foo.bar  through a mailgateway. 

And before finishing of the mailgateway config, I got a bounce back. So how can 
I fix the null client to accept but drop all bounce/rejects?
The servers were playing ping-pong back and forth with bounce mails :(

Re: Trouble adding sasl support via dovecot

[Reindl Harald]

Am 12.03.2012 18:14, schrieb Richard Troy:



please describe you problem a little shorter

with dovecot 2.x the follwoing in "dovecot.conf" is
working like a charme, if i should guess you missed
the mode/owner/group

# configure backend for postfix sasl-auth
service auth {
  unix_listener /var/spool/postfix/private/auth {
  mode = 0660
  user = postfix
  group= postfix
 }
}



signature.asc
Description: OpenPGP digital signature

Re: Trouble adding sasl support via dovecot

[Wietse Venema]

Richard Troy:
> My problem statement is simply, "it should be working", but doesn't, and I
> don't get any announcement of "auth" when testing connections to Postfix
> as per directions here:
...
> smtpd_sasl_type = dovecot
> smtpd_sasl_path = private/auth
> smtpd_sasl_auth_enable = yes
> broken_sasl_auth_clients = yes
> smtpd_sasl_security_options = noanonymous, noplaintext
> smtp_sasl_security_options = noanonymous, noplaintext
> smtpd_sasl_tls_security_options = noanonymous
> smtp_sasl_tls_security_options = noanonymous

Output from the "postconf -n" command is preferred here. If this
output differs from what you expect, then that it a possible
contributor to the problem.

See also the mailing list welcome message repeated below.

Wietse

TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail

TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html

Thank you for using Postfix.

Re: Trouble adding sasl support via dovecot

[Richard Troy]

Herr Harald,

> please describe you problem a little shorter

Ja, klein.

> with dovecot 2.x the follwoing in "dovecot.conf" is

Using 1.2.8.

> the mode/owner/group

No, not missed, however:

>   unix_listener /var/spool/postfix/private/auth {

My code reads:

path = /var/spool/postfix/private/auth

Probably just a difference in version.

Vielen Dank,
Richard

Re: Trouble adding sasl support via dovecot

[Reindl Harald]

Am 12.03.2012 18:44, schrieb Richard Troy:
>> with dovecot 2.x the follwoing in "dovecot.conf" is
> 
> Using 1.2.8

this is really old

>> the mode/owner/group
> No, not missed, however:
> 
>>   unix_listener /var/spool/postfix/private/auth {
> 
> My code reads:
> path = /var/spool/postfix/private/auth
> 
> Probably just a difference in version

not really, we are using dovecot since 2009 for
sasl-auth and as imap/pop3-proxy in front of
dbmail - the syntax of many things has changed
in 2.x but the transition last januarry was painless

however, we need LOG OUTPUTS instead descriptions






signature.asc
Description: OpenPGP digital signature

Re: Trouble adding sasl support via dovecot

[Larry Stone]

On Mon, 12 Mar 2012, Richard Troy wrote:


My problem statement is simply, "it should be working", but doesn't, and I
don't get any announcement of "auth" when testing connections to Postfix
as per directions here:

  http://www.postfix.org/SASL_README.html#server_test


I haven't seen any followups with the request postconf -n output but:

It's not clear if you're trying to do this on port 25 or port 587 
(submission). In any event, you have included permit_sasl_authenticated in 
your smtpd_recipient_restrictions, right? Since if you didn't, that would 
certainly explain a "relay access denied" reject when attempting to send 
from outside your network to outside your network. Note that 
permit_sasl_authenticated must be ahead of reject_unauth_destination.


-- Larry Stone
   lston...@stonejongleux.com

Re: Trouble adding sasl support via dovecot

[Richard Troy]

On Mon, 12 Mar 2012, Wietse Venema wrote:

> Output from the "postconf -n" command is preferred here. If this
> output differs from what you expect, then that it a possible
> contributor to the problem.

Yes, already checked: high fidelity, no discrepancies.

> TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail

Thanks, I was unfamilliar with saslfinger. However, I'm not using Cyrus,
but rather Dovecot. ...It didn't reveal any problems that I am aware of.

It should be pointed out that the client I'm testing with is an Android
phone less than three months old. It is configured to receive email
through the same server, and that works, and sending: "login required", a
valid username, security type of TLS, and port 25 - same as before this
effort began. If I tell it the security type is "ssl", it won't let the
configuration be saved and complains it can't access the server.

Because it's a live system, it's hard to be sure what messages are
related or unrelated during testing, so here's my best guess at what's one
set of data per singular connect request when Android tries to check the
connection - it's NOT trying to send an email, apparently:

Mar 12 10:59:40 fs1 dovecot: auth(default): new auth connection: pid=304
Mar 12 10:59:40 fs1 postfix/smtpd[304]: connect from
mcb0536d0.tmodns.net[208.54.5.203]
Mar 12 10:59:40 fs1 dovecot: auth(default): client in:
AUTH#0111#011LOGIN#011service=smtp#011nologin
Mar 12 10:59:40 fs1 dovecot: auth(default): client out:
CONT#0111#011
Mar 12 10:59:40 fs1 dovecot: auth(default): client in: CONT
Mar 12 10:59:40 fs1 dovecot: auth(default): client out:
CONT#0111#011
Mar 12 10:59:40 fs1 dovecot: auth(default): client in: CONT
Mar 12 10:59:40 fs1 dovecot: auth(default): passwd-file():
lookup: user= file=/etc/cram-md5.pwd
Mar 12 10:59:40 fs1 dovecot: auth(default): client out:
OK#0111#011user=
Mar 12 10:59:40 fs1 postfix/smtpd[304]: disconnect from
mcb0536d0.tmodns.net[208.54.5.203]

Any further debugging ideas?

Thanks again,
Richard

Re: Trouble adding sasl support via dovecot

[Richard Troy]

On Mon, 12 Mar 2012, Larry Stone wrote:
>
> I haven't seen any followups with the request postconf -n output but:
>
Um, nobody asked for it; Wietse only said it was preferred over sharing
the values individually. -smile- However, I'll take your statement as an
implicit request - it's below.

> It's not clear if you're trying to do this on port 25 or port 587
> (submission).

I'd be keen to know how I can, if I should, offload port 25; as I
indicated I'm using port 25 because I didn't stumble over any other course
of action. Please feel free to point me at what I _should_ be doing!
-smile-


> In any event, you have included permit_sasl_authenticated in
> your smtpd_recipient_restrictions, right?

Yes, as described in my first post here.

> Note that
> permit_sasl_authenticated must be ahead of reject_unauth_destination.

In smtpd_sender_restrictions, permit_sasl_authenticated immediately
follows permit_mynetworks. In smtpd_recipient_restrictions, it's
considerably further from being first! (as can be seen below) I'll move it
to follow permit_mynetworks and see how it goes! THANKS for the
suggestion.

>
> -- Larry Stone
> lston...@stonejongleux.com
>

Thanks Larry,
Richard


Output from postconf -n:

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 10
debug_peer_list = 192.168.2.16
disable_vrfy_command = yes
html_directory = no
inet_interfaces = all
inet_protocols = all
local_recipient_maps = unix:passwd.byname $alias_maps
mail_owner = postfix
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
mydestination = $myhostname , localhost.$mydomain , localhost, 
mydomain = myDomain.com
myhostname = mail.myDomain.com
mynetworks = $mydestination , 
mynetworks_style = subnet
newaliases_path = /usr/bin/newaliases.postfix
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.5.6/README_FILES
recipient_delimiter = +
relay_domains = $mydestination , 
sample_directory = /usr/share/doc/postfix-2.5.6/samples
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtp_sasl_security_options = noanonymous, noplaintext
smtp_sasl_tls_security_options = noanonymous
smtpd_delay_reject = yes
smtpd_helo_required = yes smtpd_helo_restrictions = permit_mynetworks,
check_helo_access hash:/etc/postfix
/helo_access, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname
smtpd_recipient_restrictions = permit_mynetworks,
reject_unauth_pipelining, reject_non_fqdn_recipient,
reject_unknown_recipient_domain, reject_unauth_destination,
permit_sasl_authenticated, check_client_access
hash:/etc/postfix/pop-before-smtp, check_sender_access
hash:/etc/postfix/sender_access, reject_rbl_client bl.spamcop.net,
reject_rbl_client sbl-xbl.spamhaus.org, check_policy_service inet:12
7.0.0.1:10030, permit_mynetworks
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous, noplaintext
smtpd_sasl_tls_security_options = noanonymous
smtpd_sasl_type = dovecot  smtpd_sender_restrictions = permit_mynetworks,
permit_sasl_authenticated, reject
_non_fqdn_sender, reject_unknown_sender_domain
smtpd_tls_cert_file = /etc/pki/dovecot/certs/dovecot.pem
smtpd_tls_key_file = /etc/pki/dovecot/private/dovecot.pem
smtpd_tls_security_level = maysoft_bounce = no
unknown_local_recipient_reject_code = 550

Re: Trouble adding sasl support via dovecot

[Wietse Venema]

Richard Troy:
> 
> On Mon, 12 Mar 2012, Wietse Venema wrote:
> 
> > Output from the "postconf -n" command is preferred here. If this
> > output differs from what you expect, then that it a possible
> > contributor to the problem.
> 
> Yes, already checked: high fidelity, no discrepancies.

You're supposed to share the result, not say "looks correct".  As
the reporter of a problem, you are in the worst position to say
that things are correct, because if you were able to see your
mistake, then you would not be posting on this mailing list
in the first place!

> Mar 12 10:59:40 fs1 postfix/smtpd[304]: connect from
> mcb0536d0.tmodns.net[208.54.5.203]
> Mar 12 10:59:40 fs1 dovecot: auth(default): client in:
> AUTH#0111#011LOGIN#011service=smtp#011nologin
> Mar 12 10:59:40 fs1 dovecot: auth(default): client out:
> CONT#0111#011
> Mar 12 10:59:40 fs1 dovecot: auth(default): client in: CONT
> Mar 12 10:59:40 fs1 dovecot: auth(default): client out:
> CONT#0111#011
> Mar 12 10:59:40 fs1 dovecot: auth(default): client in: CONT
> Mar 12 10:59:40 fs1 dovecot: auth(default): passwd-file():
> lookup: user= file=/etc/cram-md5.pwd
> Mar 12 10:59:40 fs1 dovecot: auth(default): client out:
> OK#0111#011user=
> Mar 12 10:59:40 fs1 postfix/smtpd[304]: disconnect from
> mcb0536d0.tmodns.net[208.54.5.203]

This would imply that Postfix actually does offer SASL AUTH service.

At this point I would like to eliminate you as the interpreter of
what is happening.

What do you see when you telnet to the SMTP port and greet the host
with

ehlo whatever

Then we can discuss what is actually happening, instead of your
interpretations.

Brutally honest,

Wietse

FIXED! Re: Trouble adding sasl support via dovecot

[Richard Troy]

> On Mon, 12 Mar 2012, Larry Stone wrote:
>
> > It's not clear if you're trying to do this on port 25 or port 587
> > (submission).
>
> I'd be keen to know how I can, if I should, offload port 25; as I
> indicated I'm using port 25 because I didn't stumble over any other course
> of action. Please feel free to point me at what I _should_ be doing!
> -smile-


   ...I'd still like to know if something like this is a good idea?!...

However


> > In any event, you have included permit_sasl_authenticated in
> > your smtpd_recipient_restrictions, right?
>
> Yes, as described in my first post here.
>
> > Note that
> > permit_sasl_authenticated must be ahead of reject_unauth_destination.
>
> In smtpd_sender_restrictions, permit_sasl_authenticated immediately
> follows permit_mynetworks. In smtpd_recipient_restrictions, it's
> considerably further from being first! (as can be seen below) I'll move it
> to follow permit_mynetworks and see how it goes! THANKS for the
> suggestion.



  THAT WAS IT, LARRY!


...None of the reject_* things seemed to apply, but then, well, CLEARLY
at least one of them did... Sure would be nice if the log contained the
reason for rejection, however, I'm not complaining; this community has
provided me with GREAT software for a LONG time!

THANKS AGAIN,
Richard

Re: Trouble adding sasl support via dovecot

[Richard Troy]

On Mon, 12 Mar 2012, Wietse Venema wrote:
>
> You're supposed to share the result, not say "looks correct".  As
> the reporter of a problem, you are in the worst position to say
> that things are correct, because if you were able to see your
> mistake, then you would not be posting on this mailing list
> in the first place!

...I am a literal person - tell me "keep it short" like Herr Harald did,
and I obey nicely! I figured maybe I had broken the ettiquite of this list
or something. With something like Thirty Five Years working with computers
every day, I consider it my obligation to provide a good problem statement
when I'm reporting one. I guess my initial report went over-board for
Harald's tastes, and then too far the other way for yours! No harm
intended, just watch out for those of us who take things literally!
-smile-

> This would imply that Postfix actually does offer SASL AUTH service.

Agreed, though I was expecting it to announce it, as described here:

http://www.postfix.org/SASL_README.html#server_test


> Brutally honest,

No hurt feelings, Wietse. You and the folks who volunteer your time here
are great and, frankly, I preferr "brutally honest", though many people
say so but don't!

As its working now, I'll let you get back to your previously scheduled
program(ing)!

Regards,
Richard

Re: Trouble adding sasl support via dovecot

[Noel Jones]

On 3/12/2012 12:14 PM, Richard Troy wrote:
> The documentation found here:
> 
> http://www.postfix.org/TLS_README.html
> 
> claims (intimates) that it's not possible to run a site on a self-signed
> certificate, however, there's ZERO budget for a signed certificate, so
> unless I can get one for ten bucks somewhere, that could be a

Untrue, a self-signed certificate works fine.  Be aware mail clients
will complain about an invalid or untrusted certificate.  This isn't
any different than using a self-signed cert with dovecot.

If you already have a cert for dovecot, use the same one.

If you want an inexpensive real cert, they're widely available from
reputable vendors such as rapidsslonline.com


  -- Noel Jones

Re: FIXED! Re: Trouble adding sasl support via dovecot

[Larry Stone]

On Mon, 12 Mar 2012, Richard Troy wrote:


...None of the reject_* things seemed to apply, but then, well, CLEARLY
at least one of them did... Sure would be nice if the log contained the
reason for rejection, however, I'm not complaining; this community has
provided me with GREAT software for a LONG time!


It did. "Relay access denied" comes from reject_unauth_destination firing. 
It sounds like you want it to log something like "rejected due to 
reject_unauth_destination". That's probably dangerous since it would just 
encourage some people to remove the restriction that was in the way of 
what they were trying to do. To the extent it makes you actually 
understand SMTP and Postfix better, it's probably good not to be too 
specific.


-- Larry Stone
   lston...@stonejongleux.com

Re: FIXED! Re: Trouble adding sasl support via dovecot

[Noel Jones]

On 3/12/2012 1:46 PM, Richard Troy wrote:
>> I'd be keen to know how I can, if I should, offload port 25; as I
>> > indicated I'm using port 25 because I didn't stumble over any other course
>> > of action. Please feel free to point me at what I _should_ be doing!
>> > -smile-
> 
>...I'd still like to know if something like this is a good idea?!...


Absolutely!  Many home cable/dsl providers and wifi hotspots block
access to port 25 to prevent direct-to-MX spamming, but allow the
other well-known ports reserved for user mail submission.

There are commented-out entries for submission port 587 and
(deprecated but widely used especially by smartphones) smtps port
465 in the postfix master.cf.  Many mail clients refer to submission
as TLS and smtps as SSL.  Simply uncomment those entries and restart
postfix.

You also mentioned that you're using cram-md5 authentication.  Be
aware that many mail clients only support PLAIN and/or LOGIN, so you
many need to enable those in your dovecot.conf.  These protocols are
not encrypted, but are safe when used inside a TLS/SSL connection.



  -- Noel Jones

Re: LoadShared Failover

[Kris Deugau]

Stan Hoeppner wrote:

On 3/12/2012 2:28 AM, Michael Maymann wrote:

Hi,

Stan: My question is not how I setup the solution, but how I *BEST* (best
practice) setup the loadshared/failover postfix solution I described
earlier.


I dunno if there is a BCP covering smtp submission/relay server load
balancing/fail over.  I'd make an educated guess that just about
everyone with more than one submission/relay server is using round robin
DNS.


*raises hand*

We're using Linux Virtual Servers for load-balancing all public-facing 
bits (and a handful of internal bits) of our entire mail cluster.


Once you beat the ARP configuration into shape to prevent a random real 
server from taking over the load-balanced IP it seems to work well.


We found that DNS-based round-robin strategies didn't actually balance 
the load very well.


-kgd

self-signed certificates - was Re: Trouble adding sasl support via dovecot

[Richard Troy]

Noel,

this is not a big deal to me, but here's where I became concerned about
self-signed certs:

On Mon, 12 Mar 2012, Noel Jones wrote:
>
> On 3/12/2012 12:14 PM, Richard Troy wrote:
> > The documentation found here:
> >
> > http://www.postfix.org/TLS_README.html
> >
> > claims (intimates) that it's not possible to run a site on a self-signed
> > certificate, however, there's ZERO budget for a signed certificate, so
> > unless I can get one for ten bucks somewhere, that could be a
>
> Untrue, a self-signed certificate works fine.  Be aware mail clients
> will complain about an invalid or untrusted certificate.  This isn't
> any different than using a self-signed cert with dovecot.

Here's the citation: on the page whose URL is above, second paragraph
under "Server-side certificate and private key configuration" reads to me
to _intimate_ that you'll have trouble with a self-signed certificate and,
as it operates on all your inbound email it could mean trouble - and I
quote:

"Public Internet MX hosts without certificates signed by a "reputable" CA
must generate, and be prepared to present to most clients, a self-signed
or private-CA signed certificate. The remote SMTP client will generally
not be able to authenticate the self-signed certificate, but unless the
client is running Postfix or similar software, it will still insist on a
server certificate."

Richard

Re: LoadShared Failover

[Wietse Venema]

Kris Deugau:
> We found that DNS-based round-robin strategies didn't actually balance 
> the load very well.

This looks like the same problem that was found (and solved) with
Postfix outbound connection caching; if a destination host became
slow for whatever reason, it became a fatal attractor for connections.

For example, twice as slow -> twice as many clients.

With outbound connection caching, this was solved in the Postfix
SMTP client, by limiting the total duration of an SMTP session.

For example, twice as slow -> half the number of sessions

With inbound SMTP, it is not possible to tell clients to go somewhere
else except by interposition, for example with an layer-3 proxy
(nginx), with a layer 2 switch/nat/etc, or by interposing at the
DNS level (adjust DNS replies according to server load). I don't
know if the last is in use for SMTP.

Wietse

Re: LoadShared Failover

[Wietse Venema]

There is one correction, in-line.

> Kris Deugau:
> > We found that DNS-based round-robin strategies didn't actually balance 
> > the load very well.
> 
> This looks like the same problem that was found (and solved) with
> Postfix outbound connection caching; if a destination host became
> slow for whatever reason, it became a fatal attractor for connections.
> 
> For example, twice as slow -> twice as many clients.
> 
> With outbound connection caching, this was solved in the Postfix
> SMTP client, by limiting the total duration of an SMTP session.
> 
> For example, twice as slow -> half the number of sessions

Correction: half the number of deliveries.

> With inbound SMTP, it is not possible to tell clients to go somewhere
> else except by interposition, for example with an layer-3 proxy
> (nginx), with a layer 2 switch/nat/etc, or by interposing at the
> DNS level (adjust DNS replies according to server load). I don't
> know if the last is in use for SMTP.
> 
>   Wietse
> 

Re: self-signed certificates - was Re: Trouble adding sasl support via dovecot

[Noel Jones]

On 3/12/2012 3:15 PM, Richard Troy wrote:
> 
> 
> Noel,
> 
> this is not a big deal to me, but here's where I became concerned about
> self-signed certs:
> 
> On Mon, 12 Mar 2012, Noel Jones wrote:
>>
>> On 3/12/2012 12:14 PM, Richard Troy wrote:
>>> The documentation found here:
>>>
>>> http://www.postfix.org/TLS_README.html
>>>
>>> claims (intimates) that it's not possible to run a site on a self-signed
>>> certificate, however, there's ZERO budget for a signed certificate, so
>>> unless I can get one for ten bucks somewhere, that could be a
>>
>> Untrue, a self-signed certificate works fine.  Be aware mail clients
>> will complain about an invalid or untrusted certificate.  This isn't
>> any different than using a self-signed cert with dovecot.
> 
> Here's the citation: on the page whose URL is above, second paragraph
> under "Server-side certificate and private key configuration" reads to me
> to _intimate_ that you'll have trouble with a self-signed certificate and,
> as it operates on all your inbound email it could mean trouble - and I
> quote:
> 
> "Public Internet MX hosts without certificates signed by a "reputable" CA
> must generate, and be prepared to present to most clients, a self-signed
> or private-CA signed certificate. The remote SMTP client will generally
> not be able to authenticate the self-signed certificate, but unless the
> client is running Postfix or similar software, it will still insist on a
> server certificate."
> 
> Richard
> 


That has nothing to do with self-signed vs. commercial, rather it
means the certificate must be marked for use as a "server"
certificate vs. a "personal", "email", or "client"  certificate --
client certificates are widely available for free for use with eg.
S/MIME on popular desktop mail clients.

Self-signed certificates work perfectly well on a mail server.  As
already discussed, the only issue you will experience is that your
own clients submitting mail will have to import your cert so they
don't get an invalid/untrusted message every time they connect.
This is no different than dovecot with a self-signed certificate.



  -- Noel Jones

Re: Installing postfix with mysql

[Scott Brown]

That worked! Thank you very much!



 From: Mailinglist 
To: Scott Brown  
Cc: Reindl Harald ; "postfix-users@postfix.org" 
 
Sent: Wednesday, March 7, 2012 7:17 PM
Subject: Re: Installing postfix with mysql
 
CentOS Plus repo already has the postfix-SQL rpm. Go into 
/etc/yum.repo/CentOS.repo file and exclude postfix under Base and Updates. Then 
run yum --enablerepo=centosplus install postfix - this will install the version 
you need without having to compile. 

Regards

On Mar 7, 2012, at 6:59 PM, Scott Brown  wrote:

> I want to use MySQL to manage the virtual table within Postfix. So it's not 
> that I want to just have MySQL and Postfix on the server as separate 
> applications.  I want the MySQL-enhanced version of Postfix.
> 
> 
> - Original Message -
> From: Reindl Harald 
> To: postfix-users@postfix.org
> Cc: 
> Sent: Wednesday, March 7, 2012 6:55 PM
> Subject: Re: Installing postfix with mysql
> 
> 
> 
> Am 08.03.2012 00:46, schrieb Scott Brown scottwb...@yahoo.com:
>> Hello,
>> I am trying to install Postfix with mysql on CentOS 6.0.
>> I am trying to follow the instructions at 
>> http://www.postfix.org/MYSQL_README.html
>> I downloaded the mysql libraries and source code.
> 
> why?
> 
> "yum install mysql-devel"
> 
>> The libmysql was extracted to 
>> /usr/local/mysql-connector-c-6.0.2-linux-glibc2.3-x86-32bit
> 
> AFAIK this is not mysql-devel
> 
>> When I try to run make install, I get this error:
>> bin/postconf: error while loading shared
>> libraries: libmysql.so.16: cannot open shared object file: No such file or
>> directory 
> 
> use as much system-packages as you can in as much default locations as 
> possible!

New default settings for "submission" service?

[Patrick Ben Koetter]

Wietse et al.

With the arrival of postscreen, but also before I find myself repeatedly
changing the defaults for the 'submission' service in master.cf. I believe the
changes I apply are not rooted in my local mail policies, but of general
nature.

Now that submission has become more popular I'd like to discuss if the current
settings should be modified to work better with an MTA that runs different
policies for port 25 and 587, which I believe has become the standard use case
for 'a mailserver'.

In RFC 5598 "Internet Mail Architecture" Dave Crocker writes about the
submission service:

4.3.1.  Mail Submission Agent (MSA)

   A Mail Submission Agent (MSA) accepts the message submitted by the
   aMUA and enforces the policies of the hosting ADMD and the
   requirements of Internet standards.  An MSA represents an unusual
   functional dichotomy.  It represents the interests of the Author
   (aMUA) during message posting, to facilitate posting success; it also
   represents the interests of the MHS.
   
   ...

   The hMSA takes transit responsibility for a message that conforms to
   the relevant Internet standards and to local site policies.  It
   rejects messages that are not in conformance.  The MSA performs final
   message preparation for submission and effects the transfer of
   responsibility to the MHS, via the hMSA.  The amount of preparation
   depends upon the local implementations.  Examples of aMSA tasks
   include adding header fields, such as Date: and Message-ID:, and
   modifying portions of the message from local notations to Internet
   standards, such as expanding an address to its formal IMF
   representation.
   -- http://tools.ietf.org/rfc/rfc5598.txt

This said, I think the submission service should be expanded and modified.

I would add the following filters to reject "messages that are not in
conformance" in order to gain basic transportability and better deliverabilty:

reject_non_fqdn_sender
reject_non_fqdn_recipient
reject_unknown_sender_domain
reject_unkown_recipient_domain

I'd also add header fields if the authenticated client failed to:

always_add_missing_headers=yes

And finally I'd change the current settings for smtpd_tls_security_level and
smtpd_delay_reject regarding the submission service:

smtpd_tls_security_level
I would not enforce TLS as the submission RFC only says "SHOULD" on TLS and
therefore would only set 'may' as preconfigured setting. I'd leave it to the
postmaster to set a stricter policy. I personally keep changing this all the
time since I configure and test SASL first and once that works as expected
turn to TLS. Opportunistic TLS as default would make this easier without
breaking RFCs.

smtpd_delay_reject
For convenience reasons I'd add this setting and set it to 'yes'. Eversince
postscreen has been around I've been switching to smtpd_delay_reject=no and
more aggressive filtering on port 25. I believe many have done so.
Unfortunately setting it to 'no' breaks the assigned smtpd_client_restrictions
for the submission service - the client will be rejected before it was able to
authenticate.


All in all I think these changes would make a submission service more useful
out of the box.

What do you think?

p@rick

-- 
All technical questions asked privately will be automatically answered on the
list and archived for public access unless privacy is explicitely required and
justified.

saslfinger (debugging SMTP AUTH):

Re: New default settings for "submission" service?

[Wietse Venema]

Patrick Ben Koetter:
> Wietse et al.
> 
> With the arrival of postscreen, but also before I find myself repeatedly
> changing the defaults for the 'submission' service in master.cf. I believe the
> changes I apply are not rooted in my local mail policies, but of general
> nature.
> 
> Now that submission has become more popular I'd like to discuss if the current
> settings should be modified to work better with an MTA that runs different
> policies for port 25 and 587, which I believe has become the standard use case
> for 'a mailserver'.

Indeed. Of course, not every MTA needs to provide "port 587"
submission service. Enabling an unused service by default would be
undesirable as it may produce unexpected results.

Different sites have different needs, and perhaps it is an idea to
provide *multiple* submission service examples in master.cf, all
commented out of course. The first could be the recommended one:
not allowing plaintext sessions is good as a general rule. The
second example could allow plaintext sessions (level = may) but
allow plaintext passwords only over encrypted sessions.

I would not recommend smtpd_delay_reject=no.  With that, the sysadmin
has no clue about what mail is blocked.  Even postscreen tries to
capture sender and recipient information.

Wietse

Re: self-signed certificates - was Re: Trouble adding sasl support via dovecot

[Viktor Dukhovni]

On Mon, Mar 12, 2012 at 01:15:01PM -0700, Richard Troy wrote:

> "Public Internet MX hosts without certificates signed by a "reputable" CA
> must generate, and be prepared to present to most clients, a self-signed
> or private-CA signed certificate. The remote SMTP client will generally
> not be able to authenticate the self-signed certificate, but unless the
> client is running Postfix or similar software, it will still insist on a
> server certificate."

As the author of the above quoted text, I can assure that it has
been misinterpreted. What the text is saying is that you need some
kind of certificate, not configuring any certificates at all ( by
setting "smtpd_tls_cert_file = none" and not defining '...dcert_file'
or '...eccert_file') is what's going to not work for most clients.

This is amplified by the context of the first sentense which clearly
presents the option of a self-signed cert. In the second sentense
I say that the client will want *a* server certificate, as opposed
to forgoing all certs and negotiating an anonymous TLS ciphersuite.

-- 
Viktor.

[no subject]

[Ramesh]

Hi All,

Is it possible to force sendmail on a remote host to relay all messages through 
server running postfix. 

currently email are sent through postini because domainX  MX record points to 
postini, I want sendmail on domainX to send directly to remote postfix server 
and bypass postini.

I am working on this, please send me your suggestions.

Thanks & Regards,
Ramesh

Re: relaying

[Ramesh]

Hi All,

I am sorry for posting  without subject.


Regards,
Ramesh




 From: Ramesh 
To: Postfix users  
Sent: Tuesday, 13 March 2012 11:35 AM
Subject: 
 

Hi All,

Is it possible to force sendmail on a remote host to relay all messages through 
server running postfix. 

currently email are sent through postini because domainX  MX record points to 
postini, I want sendmail on domainX to send directly to remote postfix server 
and bypass postini.

I am working on this, please send me your suggestions.

Thanks & Regards,
Ramesh

Re: New default settings for "submission" service?

[Patrick Ben Koetter]

* Wietse Venema :
> Patrick Ben Koetter:
> > Wietse et al.
> > 
> > With the arrival of postscreen, but also before I find myself repeatedly
> > changing the defaults for the 'submission' service in master.cf. I believe 
> > the
> > changes I apply are not rooted in my local mail policies, but of general
> > nature.
> > 
> > Now that submission has become more popular I'd like to discuss if the 
> > current
> > settings should be modified to work better with an MTA that runs different
> > policies for port 25 and 587, which I believe has become the standard use 
> > case
> > for 'a mailserver'.
> 
> Indeed. Of course, not every MTA needs to provide "port 587"
> submission service. Enabling an unused service by default would be
> undesirable as it may produce unexpected results.

Agreed.


> Different sites have different needs, and perhaps it is an idea to
> provide *multiple* submission service examples in master.cf, all
> commented out of course. The first could be the recommended one:
> not allowing plaintext sessions is good as a general rule. The
> second example could allow plaintext sessions (level = may) but
> allow plaintext passwords only over encrypted sessions.

I'll be on a train for quite some time today. That will give me time to work
out some examples.


> I would not recommend smtpd_delay_reject=no.  With that, the sysadmin
> has no clue about what mail is blocked.  Even postscreen tries to
> capture sender and recipient information.

You would not recommend it in general or not on 587? The latter would be my
recommendation:

- Do not delay on port 25 for MTA to MTA communication
- Delay on port 587 for MUA to MTA communication

p@rick

-- 
All technical questions asked privately will be automatically answered on the
list and archived for public access unless privacy is explicitely required and
justified.

saslfinger (debugging SMTP AUTH):