Getting around Comcast Port 25 Block with a Local + Remote Postfix Server?

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Getting around Comcast Port 25 Block with a Local + Remote Postfix Server?

Steve Jenkins-3
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=<[hidden email]>, 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=<[hidden email]>, 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
Reply | Threaded
Open this post in threaded view
|

Re: Getting around Comcast Port 25 Block with a Local + Remote Postfix Server?

Steve Jenkins-3
On Tue, Jun 18, 2013 at 9:00 AM, Rod K <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Getting around Comcast Port 25 Block with a Local + Remote Postfix Server?

Steve Jenkins-3
On Tue, Jun 18, 2013 at 9:07 AM, Steve Jenkins <[hidden email]> wrote:
On Tue, Jun 18, 2013 at 9:00 AM, Rod K <[hidden email]> 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=<[hidden email]>, 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
Reply | Threaded
Open this post in threaded view
|

Re: Getting around Comcast Port 25 Block with a Local + Remote Postfix Server?

Stan Hoeppner
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

Reply | Threaded
Open this post in threaded view
|

Re: Getting around Comcast Port 25 Block with a Local + Remote Postfix Server?

Steve Jenkins-3
On Tue, Jun 18, 2013 at 9:35 AM, Stan Hoeppner <[hidden email]> wrote:
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
Reply | Threaded
Open this post in threaded view
|

Re: Getting around Comcast Port 25 Block with a Local + Remote Postfix Server?

Al Zick
In reply to this post by Steve Jenkins-3
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=<[hidden email]>, 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

Reply | Threaded
Open this post in threaded view
|

Re: Getting around Comcast Port 25 Block with a Local + Remote Postfix Server?

Steve Jenkins-3
On Tue, Jun 18, 2013 at 9:45 AM, Al Zick <[hidden email]> 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 
Reply | Threaded
Open this post in threaded view
|

Re: Getting around Comcast Port 25 Block with a Local + Remote Postfix Server?

Stan Hoeppner
In reply to this post by Steve Jenkins-3
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

Reply | Threaded
Open this post in threaded view
|

Re: Getting around Comcast Port 25 Block with a Local + Remote Postfix Server?

Steve Jenkins-3
On Tue, Jun 18, 2013 at 11:35 AM, Stan Hoeppner <[hidden email]> wrote:
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
 
Reply | Threaded
Open this post in threaded view
|

Re: Getting around Comcast Port 25 Block with a Local + Remote Postfix Server?

@lbutlr
In reply to this post by Al Zick
On 18 Jun 2013, at 10:45 , Al Zick <[hidden email]> wrote:
> Does anyone know if Comcast will let you relay emails through there mail server that do not have a comcast email address?

Yes, they will. So will Google. Mac.com, otoh, will not (last I checked).

--
I find Windows of absolutely no technical interest... Mac OS X is a rock
-solid system that's beautifully designed. I much prefer it to Linux. -- Bill Joy