postfix munin graphs
Does anyone have all 3 munin graphs working with the postfix plugin? My mailqueue graph works but for the others I get: # munin-run postfix_mailstats delivered.value U # munin-run postfix_mailvolume volume.value U I think I need to tell munin where my postfix logs are (/var/log/mail/current) since I use metalog. How can I do that? - Grant
Re: postfix munin graphs
Tue, 18 Jun 2013 07:38:38 -0700 skrev Grant emailgr...@gmail.com: I think I need to tell munin where my postfix logs are (/var/log/mail/current) since I use metalog. How can I do that? - Grant Try'n read some documentation http://munin.readthedocs.org/en/latest/ Then check out /etc/munin/plugin-conf.d/munin-node And then, if Munin still doesn't work, the Munin-folks might be better to help out http://munin-monitoring.org/wiki/HowToGetHelp
Getting around Comcast Port 25 Block with a Local + Remote Postfix Server?
I've got a number of APC UPS units with Gen1 management cards, meaning they can only send email alerts via a local SMTP server and without any authentication. The only options the management cards support are the local SMTP server address, the From: address, and the To: address. I have a private Postfix server running in my basement, and I have it set up so that it would permit relaying for mynetworks, and mynetworks contained the specific local IPs on my private network (192.168.1.x) of each UPS management card. This used to work fine for getting alerts from my UPS units to my Gmail address... until Comcast blocked all outbound connections on port 25. :( Here's what happens if mail is sent through this local Postfix server now: Jun 18 08:40:31 mugello sendmail[20546]: r5IFeVMG020544: to= ...@gmail.com, delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=120370, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (Ok: queued as D4EF15301EE) Jun 18 08:40:32 mugello postfix/smtpd[20547]: disconnect from mugello[127.0.0.1] Jun 18 08:40:47 mugello postfix/smtp[20552]: connect to gmail-smtp-in.l.google.com[74.125.25.26]: Connection timed out (port 25) Jun 18 08:41:02 mugello postfix/smtp[20552]: connect to alt1.gmail-smtp-in.l.google.com[74.125.142.26]: Connection timed out (port 25) Jun 18 08:41:17 mugello postfix/smtp[20552]: connect to alt2.gmail-smtp-in.l.google.com[74.125.137.26]: Connection timed out (port 25) Jun 18 08:41:32 mugello postfix/smtp[20552]: connect to alt3.gmail-smtp-in.l.google.com[173.194.76.26]: Connection timed out (port 25) Jun 18 08:41:47 mugello postfix/smtp[20552]: connect to alt4.gmail-smtp-in.l.google.com[74.125.131.26]: Connection timed out (port 25) Jun 18 08:41:47 mugello postfix/smtp[20552]: D4EF15301EE: to= ...@gmail.com, relay=none, delay=75, delays=0.13/0.03/75/0, dsn=4.4.1, status=deferred (connect to alt4.gmail-smtp-in.l.google.com[74.125.131.26]: Connection timed out) So I'm wondering if there's a way to configure my local Postfix server and a remote Postfix server under my control (and at our colo, so it's off the Comcast network) so that mail accepted by the local Postfix server will relay it on a port other than 25 to the remote Postfix, after which the remote server attempts delivery as normal to my notification address. Thanks in advance, SteveJ
Re: Getting around Comcast Port 25 Block with a Local + Remote Postfix Server?
On Tue, Jun 18, 2013 at 9:00 AM, Rod K li...@23net.net wrote: If the local postfix instance isn't handling anything else (or even if it is) the easiest solution would probably be to configure it to relay everything through Comcast's SMTP server. You're absolutely right, Rod. I was so focused on figuring out a way AROUND Comcast, that I never considered going THROUGH them. I'm setting up smtp_sasl_password_maps right now. :) Thanks! SteveJ
Re: Getting around Comcast Port 25 Block with a Local + Remote Postfix Server?
On Tue, Jun 18, 2013 at 9:07 AM, Steve Jenkins stevejenk...@gmail.comwrote: On Tue, Jun 18, 2013 at 9:00 AM, Rod K li...@23net.net wrote: If the local postfix instance isn't handling anything else (or even if it is) the easiest solution would probably be to configure it to relay everything through Comcast's SMTP server. You're absolutely right, Rod. I was so focused on figuring out a way AROUND Comcast, that I never considered going THROUGH them. I'm setting up smtp_sasl_password_maps right now. :) Thanks again, Rod! Your advice was spot on: Jun 18 09:16:35 mugello postfix/smtp[25918]: EE44B5301F0: to= ...@gmail.com, relay=smtp.comcast.net[76.96.40.155]:587, delay=1.3, delays=0.14/0.03/0.38/0.77, dsn=2.0.0, status=sent (250 2.0.0 psGa1l00H0lc5WA8dsGai2 mail accepted for delivery) A good reminder that we often try to over-complicate things, and that the simplest answer is often the best. :) Cheers, SteveJ
Re: Getting around Comcast Port 25 Block with a Local + Remote Postfix Server?
On 6/18/2013 11:19 AM, Steve Jenkins wrote: A good reminder that we often try to over-complicate things, and that the simplest answer is often the best. :) You mean like using SMTP for a job best handled by SNMP or syslog? ;) IIRC both are supported by the Gen 1 APC net cards. And given your description of Colo+home, setting up a site-to-site VPN between the two would not only fix this issue, but likely many to come up in the future. -- Stan
Re: Getting around Comcast Port 25 Block with a Local + Remote Postfix Server?
On Tue, Jun 18, 2013 at 9:35 AM, Stan Hoeppner s...@hardwarefreak.comwrote: On 6/18/2013 11:19 AM, Steve Jenkins wrote: A good reminder that we often try to over-complicate things, and that the simplest answer is often the best. :) You mean like using SMTP for a job best handled by SNMP or syslog? ;) IIRC both are supported by the Gen 1 APC net cards. Yeah like THAT! ;) Although, as it turns out, I was able to get these alerts working in under 5 minutes with four lines in my main.cf: relayhost = [smtp.comcast.net]:587 smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd smtp_sasl_security_options = While setting up my at-home DD-WRT firewall to allow SNMP messages outbound to our colo-based Nagios server would have taken at least 8 minutes. :) And given your description of Colo+home, setting up a site-to-site VPN between the two would not only fix this issue, but likely many to come up in the future. That STILL sounds less simple than those four lines, but you make an excellent point, Stan (as usual). I'll look into that in anticipation of the next issue that will surely come up. :) SteveJ
Re: Getting around Comcast Port 25 Block with a Local + Remote Postfix Server?
On Tue, Jun 18, 2013 at 9:45 AM, Al Zick a...@familysafeinternet.com wrote: Does anyone know if Comcast will let you relay emails through there mail server that do not have a comcast email address? You must use a Comcast username and password to authenticate on their SMTP servers, but after that you can send mail TO any email address (which is expected), but you can also use any FROM address you like, even if it's not @comcast.net (which is surprising). SteveJ
Re: Getting around Comcast Port 25 Block with a Local + Remote Postfix Server?
On Jun 18, 2013, at 12:19 PM, Steve Jenkins wrote: On Tue, Jun 18, 2013 at 9:07 AM, Steve Jenkins wrote: On Tue, Jun 18, 2013 at 9:00 AM, Rod K wrote: If the local postfix instance isn't handling anything else (or even if it is) the easiest solution would probably be to configure it to relay everything through Comcast's SMTP server. You're absolutely right, Rod. I was so focused on figuring out a way AROUND Comcast, that I never considered going THROUGH them. I'm setting up smtp_sasl_password_maps right now. :) Thanks again, Rod! Your advice was spot on: Jun 18 09:16:35 mugello postfix/smtp[25918]: EE44B5301F0: to=...@gmail.com, relay=smtp.comcast.net[76.96.40.155]:587, delay=1.3, delays=0.14/0.03/0.38/0.77, dsn=2.0.0, status=sent (250 2.0.0 psGa1l00H0lc5WA8dsGai2 mail accepted for delivery) A good reminder that we often try to over-complicate things, and that the simplest answer is often the best. :) Does anyone know if Comcast will let you relay emails through there mail server that do not have a comcast email address? Thanks, Al
Re: Fwd: postscreen log lines reporting warnings and fatal errors
After looking at past logs an seeing the errors only began after the email gateway had been running for a few weeks, I deleted the /var/lib/postfix/postscreen_cache.db. Restarting postfix now has a happy postscreen+bdb again. -- Robert Lopez Unix Systems Administrator Central New Mexico Community College (CNM) 525 Buena Vista SE Albuquerque, New Mexico 87106
Re: Getting around Comcast Port 25 Block with a Local + Remote Postfix Server?
On 6/18/2013 11:43 AM, Steve Jenkins wrote: That STILL sounds less simple than those four lines, but you make an excellent point, Stan (as usual). I'll look into that in anticipation of the next issue that will surely come up. :) Well sure, quick hacks are always easy. Call me a purist, no frills, efficiency freak, maybe reliability freak, or just plain freak. ;) A few of salient points: 1. The header alone may be a kilobyte, for a msg body of a few dozen bytes--horrible overhead, a waste of resources. 2. An SNMP/syslog message will be one or two lines, a few dozen bytes 3. Comcast's SMTP relay may delay delivery due to any number of causes. You don't control it. You can't look at nor flush its queue. Do you need these alerts in real time? Guaranteed delivery? 4. SNMP/syslog is realtime. You control it. SNMP/syslog were designed specifically for this type of application. They are better suited. While using SMTP is not wholly inappropriate, it's far from optimal. And, is Comcast's relay infrastructure reliable in the long term for sending such alerts? -- Stan
Re: Getting around Comcast Port 25 Block with a Local + Remote Postfix Server?
On Tue, Jun 18, 2013 at 11:35 AM, Stan Hoeppner s...@hardwarefreak.comwrote: On 6/18/2013 11:43 AM, Steve Jenkins wrote: That STILL sounds less simple than those four lines, but you make an excellent point, Stan (as usual). I'll look into that in anticipation of the next issue that will surely come up. :) Well sure, quick hacks are always easy. Call me a purist, no frills, efficiency freak, maybe reliability freak, or just plain freak. ;) A few of salient points: You're the hardware freak, Stan. There's no shame in being freaky. :) 1. The header alone may be a kilobyte, for a msg body of a few dozen bytes--horrible overhead, a waste of resources. 2. An SNMP/syslog message will be one or two lines, a few dozen bytes 3. Comcast's SMTP relay may delay delivery due to any number of causes. You don't control it. You can't look at nor flush its queue. Do you need these alerts in real time? Guaranteed delivery? 4. SNMP/syslog is realtime. You control it. I will certainly look into a longer term VPN solution, since it will give me the most flexibility moving forward. I've already got one VPN set up here at the house, so I can authenticate on the local domain and grab files, control client devices in the house, etc. Setting up SNMP without the VPN will require a bit of kung fu to get through the Linksys router, epsecially for 6 different UPS units with 6 different UP addresses. Also, I'm not the only person who gets alerted when a Nagios-monitored resource goes critical. The other admins won't be too thrilled if they're woken up by the UPS in my home office announcing a power outage. :) But to get past some issues in your item #3, I actually re-configured it to authenticate and relay through one of my own personal Postfix boxes at the colo, instead of relying on Comcast's SMTP servers. I also figured out how to do it with Gmail's servers (unlike Comcast, Gmail and my Postfix box both require smtp_use_tls=yes). I settled on using my own. Son now I CAN look at and flush the queue (let's add control freak to your list of benevolent freakish qualities... cuz control in this case is a GOOD thing). Also, by relaying through one of my personal boxes, I can now DKIM-sign the alerts and make sure they pass SPF, without needing to add PTR records to my zone files. Yes, that adds to the size of the header, but at least I get something in return. SteveJ
Re: Problem using TLS: lost connection after STARTTLS
On Sun, Jun 16, 2013 at 11:13:05AM +0200, Jan P. Kessler wrote:
Disable TLSv1.1 and TLSv1.2 for this destination. Use the protocols
attribute in the Postfix policy table.
Thanks, that worked (postfix 2.8.13):
policy_table:
[mxtls.allianz.com] verify protocols=SSLv3:TLSv1
With the destination domain in [], or when match=... is explicitly
specified, the verify and secure levels are identical, otherwise
I would probably shun verify and use secure with explicit match
clauses as required.
Currently I fear, that other partners might be also affected about this.
Now the queues are almost empty but most traffic with other mandatory
TLS partner sites will start to continue during work hours Mo-Fr and
I'll be out of office for a week. What do you think about deactivating
v1.1 and v1.2 globally?
Unlikely to cause any harm, and may help with some destinations.
You lose support for AEAD modes which protect against CRIME and
BEAST, but those attacks are browser-specific.
smtp_tls_mandatory_protocols = !SSLv2
smtp_tls_protocols = !SSLv2
Suggestion:
smtp_tls_mandatory_protocols = !SSLv2 !TLSv1.1 !TLSv1.2
smtp_tls_protocols = !SSLv2
You can set both the same for now. Ideally there'll be some pressure
on sites with broken TLSv1.2 (TLSv1.1 is a far more modest change)
to get their implementations upgraded. But if you have critical
traffic, it may be reasonable to be conservative in what you send...
Will this work or are we expected to run into other compatibility issues
with that from your experience?
TLSv1 is tried and true and largely sufficient, it is a very safe choice.
P.S.: On one machine I tried to switch to a shared openssl 1.0.1e build
which also seems to work fine:
# ldd /opt/vrnetze/postfix/libexec/smtpd|grep -i ssl
libssl.so.1.0.0 = /opt/vrnetze/openssl/lib/libssl.so.1.0.0
libcrypto.so.1.0.0 =/opt/vrnetze/openssl/lib/libcrypto.so.1.0.0
Am I right concluding that this won't require a postfix rebuild on new
openssl 1.0.x versions?
I can't speak for the stability of the OpenSSL ABI. It is *supposed*
to work, whether it will, only time will tell. Many other users will
rely on this stability on systems where 1.0.0 or 1.0.1 is the default
OpenSSL library:
$ openssl version
OpenSSL 1.0.1e 11 Feb 2013
$ ldd $(type -p openssl) |
grep /usr/lib |
awk '{printf %-20s %s\n, $1,$3}'
libssl.so.1.0.0 /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
libcrypto.so.1.0.0 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
--
Viktor.
