Verizon FIOS Blocking SMTP Port (Outgoing Email)

Posted on June 10, 2010 by kevinlawry

The Long Story…

I recently found out the hard way that the Verizon FIOS Internet Service Provider (ISP) has implemented port blocking for outgoing (SMTP) email to non-Verizon mail servers. I use a third-party POP3/SMTP mail server that comes with my web hosting account (I avoid using the free email accounts that come with ISP’s like Verizon to avoid changing my email address every time I switch Internet providers). Yesterday, I noticed that my Outlook 2007 was unable to send an email. It just sat in my outbox after repeated attempts to send-and-receive. I gave up and shut down my computer for the night assuming that a reboot would fix the problem.

This morning, I tried sending the same email with the same result. Outlook kept saying it was unable to access the outgoing SMTP mail server. I was able to download email via POP3 and I was able to access my webmail. So I tried sending email through one of my web applications which uses SMTP, and to my surprise, that worked fine.

I was starting to write an email to my web host complaining that they must have changed their SMTP authentication to block external IP addresses from sending email. Then it hit me – maybe my web host isn’t the one blocking traffic. The problem could be with Verizon. So I searched around a bit and found an announcement from Verizon that explained the whole thing. I changed my Outlook settings and now I’m back in business. I’m glad I didn’t send that angry support email to my web host. :-)

Long Story Short…

Verizon FIOS is blocking outgoing (SMTP) email on Port 25. They’ve been rolling out this change since 2009 but apparently didn’t inform all of their customers. They say they’re doing it to reduce the spread of email viruses.

The “solution” is to change your SMTP port. Thankfully, many email providers (including mine) support Port 587 as an alternate SMTP port. Unfortunately, there will be some users who don’t have that option and are stuck not being able to send mail at all. Those unlucky folks will need to talk to their email provider or drop Verizon as their ISP.

If you’re having trouble sending mail using Verizon FIOS, check out the following links:

Kick it on DotNetKicks.com [Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

Filed under: How To | Tagged: , , , | 10 Comments »

How To: Flush Response Buffer in Castle MonoRail

Posted on January 26, 2009 by kevinlawry

I recently had a MonoRail project where client-side performance was becoming a problem.  A Portlet (an extended View Component) in our master template was calling a web service multiple times during page generation, which often caused a delay in the browser download and therefore caused user complaints, which (naturally) led to our client complaining.  For a number of reasons, there was no simple way to make the web service call asynchronous.

The “quick fix” solution was to implement as many client-side performance improvements as possible.  I reviewed Yahoo’s “Best Practices for Speeding Up Your Website” and realized there was something I hadn’t tried.  Yahoo suggests “flushing the response early”, recommending that you flush between the </head> and <body> tags.  The example in PHP is great, if I were using PHP.  :-)

By default ASP.NET buffers the response until the whole page is generated (web service requests and all).  This delay causes the browser to appear to freeze for a couple of seconds after the user clicks a link.  Users would click a link and think it didn’t work, so they clicked it a second time, third time, etc.  If I could flush the response after the </head> and after the header/main-menu HTML then the browser would show something happening faster and the users would stop being click-happy (or click-angry).

To disable response buffering for an individual page in ASP.NET you can add buffer=”false” to the page directive as shown here:

To disable response buffering for an entire web application you can add buffer=”false” to the <pages> setting under <system.web> as shown here:

<system.web>
    <pages buffer="false" />
</system.web>

Since MonoRail is an httpHandler for ASP.NET, the same setting in web.config applies.  It should also be possible to change the setting on a single MonoRail controller action by specifying the following inside the method code as shown here (on sample Index page):

public void Index()
{
    Context.UnderlyingContext.Response.Buffer = false;
}

The next trick is to explicitly force the flush within the page inline with the HTML that should be broken up.  In ASP.NET you could simply insert Response.Flush() into the page as shown here:

</head>
<% Response.Flush(); %>
<body>

In MonoRail the same idea applies but with slightly different syntax.  The Response.Flush() method can still be accessed but requires a more complex path due to MonoRail’s namespace layout.  With NVelocity, the code looks like the following:

</head>
$Context.UnderlyingContext.Response.Flush()
<body>

After applying those changes to my project, response flushing appeared to work in MonoRail…  until I rolled it out to our production environment.  The final gotcha was that our HTTP Compression (GZip & Deflate) settings in IIS were interfering.  I opened ZipEnable and told IIS to cease compressing dynamic content and suddenly response flushing worked.  So apparently the HTTP compression in IIS buffers the entire page content before compressing and delivering to the client browser.

Lesson of the Day:

Even though I disabled HTTP compression for dynamic content and it technically took ~1 sec longer for total download on the client browser, users thought that the site was far faster.  Actual speed is not as important as perceived speed.  If the browser seems to immediately respond to a click, the user is more satisfied because something appears to be happening even if the page doesn’t completely fill-in right away.

Browser Performance Tip:

Response.Flush() can be used strategically multiple places within a page.  I use it immediately after the </head> tag, also after the header/main-menu HTML and sometimes after large div containers like sidebar navigation.

Another quick tip is to move as many JavaScript includes as possible to the bottom of your HTML (just before the closing </body> tag), then put a Response.Flush() before the <script> tags.  Why? Because browsers often pause rendering while they are downloading JS files in case there is inline content to be rendered.  Flushing the response before the JavaScript file references will let the content render faster.  Of course, some JavaScripts can’t be moved due to inline rendering or dependency issues, but you can experiment with which scripts can be pushed to the bottom to be loaded last.

I hope this post is helpful to you MonoRail fans out there.  Happy coding!

Kick it on DotNetKicks.com [Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

Filed under: How To | Tagged: , , , | 1 Comment »

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: