[SOLVED] Can relaying be allowed for authenticated users?

[dwmtractor]

I got mine working over the weekend (thanks to Bill for helping me think it through), and it may be that my issue (which wasn't where I expected) affects some of the rest of you. Turns out it was due to the way my firewall handled the translation of IP addresses from the DMZ to the public. My settings are as follows:

My mailserver, mail.tractor-equip.net resolves (as anybody can check with nslookup or dig) to 12.181.168.155. That is actually a secondary IP address on the external ethernet port of my firewall.

The actual mailserver resides in a DMZ 10.3.2.xxx, which is a subnet that is inaccessible to the outside world.

I had the firewall set up to do Destination Network Address Translation (DNAT) so that any traffic from the outside world for port 25 (SMTP) or 443 (https) would get translated from 12.181.168.155 to 10.3.2.xxx. (later I added the IMAP and POP ports too) However, I didn't realize it at first, but all the OUTGOING traffic from the mailserver was not coming from that same address, but from the primary WAN address of the firewall (due to another NAT rule). This was preventing any of my external clients from logging in for external pop, IMAP, or SMTP, because the return traffic was not coming from 12.181.168.155.

Once I set up a second SNAT (Source Network Address Translation) rule to make the outgoing traffic from my mailserver to come from 12.181.168.155 rather than the other WAN address, I was able to log on successfully and both send and receive mail. I tested it from home using a Thunderbird client. Key issue--if you're using DMZ and NAT, be sure the incoming and outgoing traffic are on the same public IP address--and this is a firewall issue, not Zimbra's problem.

SSS, I would NOT recommend you use the clear text login or non-secure ports for your external access (as you well know already), and I was able to connect without them enabled. My settings are

• enabling POP, IMAP and SMTP over SSL
• TLS enabled
• External Auth enabled
• cleartext login DISabled.

Your firewall, of course, has to pass the proper ports for each service: 993 for IMAP-SSL, 995 for POP-SSL, and 465 for SMTP-SSL. I actually block 110 (cleartext POP) and 143 (clear IMAP) at the firewall since they are less secure (but don't block 25 SMTP or you won't get mail from anybody else ).

I can't speak to other clients, but with Thunderbird enabling SSL for POP, IMAP, and SMTP, and enabling the username and password for SMTP, did the trick.

Hope this helps,

Dan

[SSS]

Originally Posted by dwmtractor

SSS, I would NOT recommend you use the clear text login or non-secure ports for your external access (as you well know already), and I was able to connect without them enabled.

Yes. I have it enabled for the moment as I'm prepping the Zimbra server to take over from our old qmail based email server which uses basically no authentication. When the zimbra server is in and I've sorted any transition issues I can then look at getting clients switched to using SSL and disabling clear text.

With regards to IMAP in my previous post, I gave it a test today and with SSL enabled I could successfully send/receive emails ok.

Originally Posted by dwmtractor

I can't speak to other clients, but with Thunderbird enabling SSL for POP, IMAP, and SMTP, and enabling the username and password for SMTP, did the trick.

With those settings on my server I too got Thunderbird and Outlook Express working.

[dwmtractor]

We have had at least three posters in this thread state that their issues have been solved, but we have not heard from original poster EdMartin. Ed, are you still having issues, or is yours working now too?

If we don't hear from Ed in a while I'll mark this thread as solved, but waiting to see how he's doing. . .

[EdMartin]

Sorry for the silence. I've been dealing with other peripheral trauma. Our company changed ISP from BellSouth to AT&T, all our public IPs changed, we lost all DNS access. We just discovered the reason was that AT&T had misconfigured the CISCO router they had supplied us with. I'm still clearing up the debris from all those goings-on. I hope to get back to this issue once calmer waters prevail for a day or two and I can gather my thoughts.

[EdMartin]

To respond to Phoenix's question from a lifetime ago, here's what I get when executing "dig imacs.org mx" from within the office LAN:

; <<>> DiG 9.4.1-P1 <<>> imacs.org.mx
;; global options: printcmd
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9198
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;;imacs.org. IN MX

;; ANSWER SECTION:
imacs.org. 5568 IN MX 10 mail.imacs.org

;; ADDITIONAL SECTION:
mail.imacs.org. 6692 IN A 12.29.155.11

;; Query time: 21 msec
;; SERVER: 192.168.1.253#53(192.168.1.253)
;; WHEN: Wed Dec 5 20:01:09 2007
;; MSG SIZE rcvd: 64

The SERVER mentioned there is the DNS server on our office LAN.

In the HELO response you highlighted from my zimbra.log snippet, 192.168.99.100 is the IP of my laptop on my home network. Why is that showing up in the Zimbra log, and how do I make the HELO response be something else?

Frequently in zimbra.log, I see these reports:

mail postfix/smtpd[4577]: warning: cannot get certificate from file /opt/zimbra/conf/smtpd.crt
mail postfix/smtpd[4577]: warning: TLS library problem: 4577:error:02001002:system library:fopen:No such file or directory:bss_file.c:352:fopen('/opt/zimbra/conf/smtpd.crt', 'r'):
mail postfix/smptd[4577]: warning: TLS library problem: 4577:error:20074002:BIO routine:FILE_CTRL:system lib:bss_file.c:354:
mail postfic/smtpd[4577]: warning TLS library problem: 4577:error 140DC002:SSL routines:SSL_CTX_USE_certificate_chain_file:system lib:ssl_rsa.c:720:
mail postfix/smtpd[4577]: cannot load RSA certificate and key data

The Zimbra mail server has two NIC cards, one with a public IP and the other on the office LAN. I notice zimbra.log references to postfix connecting to and disconnecting from

mail.imacs.org[192.168.1.150]

and this IP is on the office LAN. Is that significant? If so, and it's not what it should be, how do I change it?

[dwmtractor]

I think you may have just given us the key to your problems, Ed, though I can't be sure because I handle the public/internal IP stuff by a firewall-mediated DMZ on another box, and my Zimbra box has only one ethernet card.

However, you just told us (and my own nslookup confirms) that when people in the outside world log into your server, they're going to us the ip address 12.29.155.11 for mail.imacs.org. That address is not authorized to relay mail out of the domain, because back at the beginning you gave us your allowed networks:

 postconf mynetworks
 
mynetworks = 127.0.0.0/8 208.62.28.224/27 192.168.1.0/24

I believe, if you add 12.29.155.11/32 to your allowed networks, relaying may work.

But I also wonder what the range 208.62.28.224/27 in your mynetworks is for; it's clearly not your mapped public IP, and yet I don't think that range is private either. . .is it a network you want to have relay access?

Dan

Dan

[EdMartin]

Sorry. Should have explained. The 208.62.28.224/27 subnet was the public IP block we had from BellSouth. Now that we have changed to AT&T, we have been assigned the 12.29.155.0/27 block. In mynetworks I have already made the switch. Here's the current output:

zimbra@mail:~$ postconf mynetworks
mynetworks = 127.0.0.0/8 12.29.155.0/27 192.168.1.0/24

We allow relaying from that entire subnet because it includes a web farm of web servers that are constantly sending out what are essentially logging messages and web transaction receipts, etc. That side of things is working fine and always has been.

[dwmtractor]

Well, given the TLS errors you described above, I'm thinking it might be worth re-creating your certificates (are you using self-signed certs. or commercial ones?) according to this wiki article. Then just in case there are certs there but the permissions are off, you might try running

/opt/zimbra/libexec/zmfixperms

These are stabs in the dark, but running them won't hurt and it might help if the certs are really not there or inaccessible.

I wish someone who actually has a Zimbra server with more than one NIC active on that server would jump in here. I have a bad feeling that your issues might involve this piece--either because the server is sending all its outgoing traffic through the "wrong" IP, or some other routing/identity issue. However, since that's not my setup I can't comment with any certainty.

This issue would become more clear, I suspect, if you try a session (even though we know it'll fail) and then tail your log files to see what errors happen in that timeframe. Failing that, a packet sniffer on the subnet that your users are connecting through might reveal some instructive information. The unfortunate reality is that the errors returned by the client program (or the lack of error message) often has little bearing on what's actually going wrong. . .

[EdMartin]

Well, color me excited! Darned if the darn thing didn't start working after regenerating the (self-signed) certificates -- as you suggested, Dan (and -- many moons ago -- Phoenix). I can now send to and receive from anywhere no matter where I am, whether using the web interface, a standalone IMAP client (to wit, Thunderbird), or the Zimbra Desktop alpha.

Makes me wonder if I wasn't actually generating those certificates for the first time. Weren't they supposed to have been produced and put in place during ZCS installation? My experience suggests that there must have been some kind of failure in that regard.

Muchas gracias to all participants in this thread. From my point of view, the saga is over ... unless there are aspects of this scenario that others want to keep going.

Signed, one happy (non-paying, open source) customer!

[phoenix]

Glad you've got it working. The certificates should be regenerated during an install, it doesn't usually fail but of course anything's possible. You'd have to check in your install logs to see if anything went wrong with the certificates but I doubt it did.

If this ever happens again I'd suggest looking at the Certificates in Thunderbird (or whatever client is being used) and delete the currently installed certificate, restart the client and accept the certificate.