Maumar-Notes

Zimbra and Italian PEC

08/08/2011 - As every italian zimbra syadm, i am faced with pec and zimbra-pec integretion.

Maybe I am near to solve it


All interesting references

http://bugzilla.zimbra.com/show_bug.cgi?id=14526

http://wiki.zimbra.com/wiki/Relay_per_Domain

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

http://www.postfix.org/SOHO_README.html#client_sasl_sender

http://www.zimbra.com/forums/italian/51496-zimbra-e-la-pec.html#post224222

Postfix SMTP client does not support TCP port 465

We have an issue: zimbra can connect to submission 587 port, *only*.

Aruba, in italy, accept connection on 465 port (old and deprecated, but aruba is aruba)


Here it is explained in detail:


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


 The Postfix SMTP client does not support the obsolete "wrappermode" protocol, 
 which uses TCP port 465 on the SMTP server. 
 See TLS_README for a solution that uses the stunnel command


I have implemented stunnel solution, but I is unuseful at all; we cannot do sasl authentication on a cleartext port; i cannot do sasl tls authetication on port 11125 that with stunnel is redirected to aruba:465

for whom interested, this is my tail main.cf:


#
# maurizio 07-08-2011
#
smtp_sender_dependent_authentication = yes
sender_dependent_relayhost_maps = hash:/opt/zimbra/postfix/conf/sender_relay
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/opt/zimbra/postfix/conf/sasl_passwd
cat sender_relay
# Per-sender provider; see also /etc/postfix/sasl_passwd.
#    user1@example.com               [mail.example.com]:submission
#    user2@example.net               [mail.example.net]
xxxx.xxxx at apservice.biz           127.0.0.1:11465
cat sasl_passwd
# Per-sender authentication; see also /etc/postfix/sender_relay.
#    user1@example.com               username2:password2
#    user2@example.net               username2:password2
xxxx.xxxx at apservice.biz           apservice at pec.cost.it:password


tail /etc/stunnel/stunnel.conf
[smtp-tls-wrapper]
accept = 127.0.0.1:11465
client = yes
connect = smtps.pec.aruba.it:smtps

The stunnel workaround

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


Client-side SMTPS support

Although the Postfix SMTP client by itself doesn't support TLS wrapper mode, 
it is relatively easy to forward a  connection through the stunnel program if Postfix needs 
to deliver mail to some legacy system that doesn't support STARTTLS. Use one of the following 
two examples, to send only some remote mail, or to send all remote mail, to an SMTPS server. 

Sending all remote mail to an SMTPS server
The first example uses SMTPS to send all remote mail to a provider's 
mail server called "mail.example.com".

A minimal stunnel.conf file is sufficient to set up a 
tunnel from local port 11125 to the remote destination "mail.example.com" and port "smtps". 
Postfix will later use this tunnel to connect to the remote server.

    /path/to/stunnel.conf:
       [smtp-tls-wrapper]
       accept = 11125
       client = yes
       connect = mail.example.com:smtps

To test this tunnel, use:

    $ telnet localhost 11125

This should produce the greeting from the remote SMTP server at mail.example.com.

Configuring Sender-Dependent SASL authentication

Postfix supports different ISP accounts for different sender addresses (version 2.3 and later). This can be useful when one person uses the same machine for work and for personal use, or when people with different ISP accounts share the same Postfix server.

To make this possible, Postfix supports per-sender SASL passwords and per-sender relay hosts. In the example below, the Postfix SMTP client will search the SASL password file by sender address before it searches that same file by destination. Likewise, the Postfix trivial-rewrite(8) daemon will search the per-sender relayhost file, and use the default relayhost setting only as a final resort.

   /etc/postfix/main.cf:
       smtp_sender_dependent_authentication = yes
       sender_dependent_relayhost_maps = hash:/etc/postfix/sender_relay
       smtp_sasl_auth_enable = yes
       smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
       relayhost = [mail.isp.example]
       # Alternative form:
       # relayhost = [mail.isp.example]:submission
   /etc/postfix/sasl_passwd:
       # Per-sender authentication; see also /etc/postfix/sender_relay.
       user1@example.com               username2:password2
       user2@example.net               username2:password2
       # Login information for the default relayhost.
       [mail.isp.example]              username:password
       # Alternative form:
       # [mail.isp.example]:submission username:password
   /etc/postfix/sender_relay:
       # Per-sender provider; see also /etc/postfix/sasl_passwd.
       user1@example.com               [mail.example.com]:submission
       user2@example.net               [mail.example.net]

Zimbra bug on Configuring Sender-Dependent SASL authentication

So, you have your account primary and many personalities.

You configure one of them with PEC credentials and data.

E.g.:


    pincopallo@pec.dominio_con_pec.it

You should configure this account on sender_relay:

  /opt/zimbra/postfix/conf/sender_relay
    
    pincopallo@pec.dominio_con_pec.it         mail.example.net

but this does not work!

Even if you send out an email using your pec personality, zimbra use always the primary one.

Free SSL

Freessl are installed.

I was faced with task of installing RapidSsl; i started with freessl as trial. I followed wiki on commercial 5.x but there is no way to install them using Admin GUI; using the CLI,instaed, they were installed like a charm.


Unified Communications Certificates (UCC)

Now, i am faced with this issue, but no zimbra employer has yet answered related post.

21-08-2008 as freessl cert is near to expire, i bought a final rapidssl cert paying it 18$ only (i cannot say where i get it, though) it was a nightmare to install it. i received it by mail and i save it without adding a cr at the end of last line.

zmcertmgr does concat

zmcertmgr does concat commercial.crt with commercial_ca.crt, and withou ending cr u get:


END CERTIFICATE----------BEGIN CERTIFICATE-----

finally, i discovered this small issue and i files a bug into bugzilla

Jump to: navigation, search