CoNetrix

Blog: Email

Recently, we had received reports from several external parties that they were unable to send email to conetrix.com addresses. The NDR message reported "MX record not found for conetrix.com".
 
Simple solution, right? Not our problem. I checked several external and global DNS caches including OpenDNS, CloudFlare, and Google, and all successfully resolved records without issue. One aspect that all parties had in common was they were sending email via Gmail, specifically Google Apps accounts. I've got a Google Apps account on a personal domain, so I sent a test email that was delivered without any issues. At this point, we figured it was a transient issue and moved on.
 
Except it wasn't. Over a period of time, it became apparent that this issue was still occurring with fair regularity and that there was something still going on. So what if this actually is our problem? What could any possible solution be?
 
I had taken vacation during the troubleshooting period and came back to the office following my PTO with a mini-epiphany. We host our own DNS records. Could it be possible that these Google Apps customers couldn't connect to our nameservers to resolve the MX records correctly?
 
On a whim, we updated the geoblocking rules on our external firewall cluster to allow inbound DNS requests from any country (not any traffic, only DNS requests). After reaching out to the external parties to send us new email, those messages were successfully delivered and we have not seemed to have had any issues since then.

I don't know why unencrypted Google Apps DNS requests were routed through foreign countries – especially countries that were added to our geoblocking list as housing potentially malicious traffic – but it seems pretty likely that this was the case.
 
Email, Geoblocking,
 

I’ve been migrating Exchange customers from Barracuda ESS over the past few months and recently ran into a small issue. I had logged into the BESS portal one morning and decided to go ahead and start cleaning up some of the domains that were registered so that Barracuda would stop routing email for these customers.

It was a simple enough process – Click the Domains tab, find the domain to remove, click Remove. Everything magically disappears.

I removed 23 domains and called it good for the morning and proceeded to work on other things. A few days later, we get a task from a customer who was unable to receive email from another customer of ours who was still using Barracuda ESS. After tracking down the logs in Customer #2’s BESS portal, I discovered that BESS was still routing email internally instead of respecting MX records.

A quick phone call to Barracuda Support and they immediately escalated the case to Tier 2/3 and Product Development. I heard back from them later that afternoon and was informed that I was removing the domains incorrectly.

I didn’t think I could screw up clicking a “Remove” button, but apparently I did.

After another minute or two of explanation, my support rep explained that the issue was really because the domains I had removed that included Aliases. There’s apparently an acknowledged bug with the portal that requires you to un-alias all domains before removing the parent domain from the portal. They checked all 23 domains I sent and verified we were good to go.

Networking, Email, Barracuda,
 

I recenly rebuilt a vCenter environment for a customer. We decided to use the vCenter Server Appliance 6.5. The configuration of the vCenter Server Appliance was fairly simple and operates very similar to vCenter Server installed on Windows. We attempted to setup email alerts, but were unable to get the alerts to send. We initially thought the alerts would not send due to an issue with the SMTP relay. Since this was not a Windows OS, I was not able to login to the OS and test the STMP relay using telnet. I checked my configuration of email alerts several times and the administrator of the SMTP servers checked his as well and everything looked correct on both sides, but emails still would not send.

After researching for quite some time, I found that I could use the "mailq" command to view the email queue on the vCenter Server Appliance. I connected to the vCenter Server Appliance via SSH, ran the "shell" command to get to the full shell, and then ran the "mailq" command. This showed me that several messages were in the mail queue and not being sent. I began to troubleshoot this more and eventually found an VMWare article regarding a bug in the vCenter Server Appliance 6.5 that prevented SMTP from working correctly. This article had been published one day before I found it, which was about a month after I first started troubleshooting the issue. From looking at the files, the original code had the wrong patch in the sendmail.cf file. 

Here is a link to the VMWare article with instructions on how to fix the bug: https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2148396

The following must be done to successfully SCP the file to the vCenter Server Appliance: https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2107727

Networking, Email, VMware, vCenter,
 

Example Error Message

Delivery has failed to these recipients or groups:

zixvpmgateway@zixvpm.domain.com

A prolem occurred while delivering this message to this email address. Try sending this message again. If the problem continues, please contact your help desk.

The following organization rejected your message: xxxxxx.ess.barracudanetworks.com. 

Overview 

This post is intended to provide a high-level overview of the routing and delivery between two companies who utilize a ZixGateway and the Barracuda Email Security Service to encrypt and scan their messages. In addition, this document will cover a common delivery issue between these same companies. [more]

Prerequisites

  • Both companies have a ZixGateway Email Encryption virtual or physical appliance
  • Both companies use Barracuda Email Security Service for antispam/antimalware scanning
  • The sending company has configured the Barracuda Email Security Service to scan all outbound email

Procedure

When a ZixGateway customer sends an email to another ZixGateway customer, the sending appliance is aware that both customers use Zix encryption and will automatically encrypt the email before delivering it. This is seamless to end users on both sides and makes email delivery between the two automatically secure.

As an email is encrypted, the sending ZixGateway wraps the entire email up as an encrypted attachment and redirects the message to zixvpmgateway@zixvpm.recipientdomain.com. Looking at this email after it has been encryption will only reveal the sender’s email address, the subject line of the message, and the modified recipient’s email address.

At this point, any mail gateway will look up MX records for zixvpm.recipientdomain.com and deliver it normally until the message reaches the destination ZixGateway. This recipient gateway will unwrap the encrypted attachment (i.e. decrypt the email), and deliver it as normal to the original recipient.

 

Because of this, a significant number of ZixGateway and Barracuda customers may set up two sets of MX records like below:
 
;; ANSWER SELECTION:
fabrikam.com. 3600 IN MX 10 d12345a.ess.barracudanetworks.com.
fabrikam.com. 3600 IN MX 20 d12345b.ess.barracudanetworks.com.
 
;; ANSWER SELECTION:
zixvpm.fabrikam.com. 3600 IN MX 20 Zixgateway.fabrikam.com.
 
This method is acceptable and fairly common from a ZixGateway point of view. From the ZixGateway, the appliance is listening to all IP addresses for incoming email, but if the incoming email is not encrypted, it will be silently dropped. This protects the ZixGateway from being overrun by spam and malicious attempts. Plus, there's no reason to send the encrypted email through a spam filter - Barracuda is unable to see inside the encrypted attachment.
 
The Barracuda Email Security Service utilizes a feature to improve the efficiency of mail routing inside their network. For mail sent between two BESS customers, instead of performing an MX record lookup for every email that passes through their system, they perform an internal lookup inside their customer database and deliver it according to the settings there. In addition, if a subdomain doesn't exist under the account, BESS will look up the root domain for delivery settings.
 
This means that in the case of the example above, mail will bypass the ZixGateway entirely, because BESS will intercept the message and deliver it to the fabrikam.com domain setting. At this point, the internal mail server will reject the message as undeliverable.
 
 
 

 
Workaround
 
The solution to this problem is a simple workaround for the recipient domain. Inside Barracuda, set up a new domain for the zixvpm.domain.com subdomain that delivers to the ZixGateway and add the zixvpmgateway@zixvpm.domain.com user to that subdomain.
 
However if outbound email routing does not flow through Barracuda and SPF is enabled on the email domain, you will need to add the Zix hostnames to the SPF exempt list.
 
Despite Barracuda not being able to scan the encrypted email, this ensures that mail delivered between BESS customers reaches its intended destination while not altering mail flow for all other email traffic. 
Networking, Email, Barracuda, ZixGateway,
 

We recently needed to create SPF records for one of our customers’ several email domains. Sender Policy Framework is implemented as a DNS TXT record and it’s designed to provide a mechanism to allow an email server to verify the valid IP addresses for a given email domain. The syntax can be a little tricky so I found several good sites to help generate the SPF. One of the best was Microsoft’s, which retrieves the actual IP addresses from DNS to build the TXT record. After you answer a few questions about email flow it creates the record which you can copy/paste into your DNS configuration.
 
https://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/
 

Networking, SPF, SPAM, Email, DNS,
 

I was subscribing to a mailing list that uses the Sympa software. This works like most of these systems - you give it your email address and it sends a confirmation email to that address with a link in it to click on to prove that you have control of that email address. This prevents someone from subscribing for another person.

I got the confirmation email right away and when I clicked on the link, I went to the web site as expected, but it gave me the message "Sorry, this operation can't be performed... The validation link has already been validated from host x.x.x.x. If you did not perform this validation, please report this confidentiality issue to your mail services administrator."

I thought "who has been reading my e-mail and clicking on links for me?" Well, that IP address belongs to Barracuda Networks, Inc. The email filtering software activated the link while checking it for malware.

Networking, Email, Barracuda, Sympa,
 

Upon installing an Adobe update on a PC, it installed Chrome as the new default browser.  After the installation finished, Chrome was uninstalled.  Sometime later, the user found they couldn't click on any URL links in Outlook messages without getting an error message.  The solution is to either remove certain registry entries left behind by Chrome or reinstall Chrome. In this case, Chrome was reinstalled and IE was left as the default browser and everything began to work.
General, Email, Outlook, Chrome,
 

If you want to receive large email attachments (up to 50 Mb) using Exchange, there are several places that need to be checked to make sure large attachments are allowed.

The first place is on the Exchange Server. Within the Exchange server, there are actually a few different places this will need to be set:

  • The first one is a global setting, in the Transport Settings (Organization Configuration/Hub Transport/Global Settings tab/Transport Settings properties/General tab). 
  • The next place you'll need to look is in each receive connector (Server Configuration/Hub Transport/Tranport Server/Receive Connectors/Connector Properties/General tab).  Each connector has its own size limit. 
  • The last place you'll need to check in Exchange is under the recipient's mailbox (Mail Flow Settings tab).

You may also need to make changes in other products (i.e. email filtering) as well. 

  • If you have Barracuda filtering the default limit may already be set to 100 Mb.
  • If your customer has a ZixVPM/ZixGateway, the default limit may be 25 Mb, so it will need to be increased if you need to receive emails larger than that.
  • Finally, check your Firewall and/or Border router for any smtp inspection statements or smtp fixup.  If any of these exist it may prevent large emails (i.e. larger than 20 Mb) from getting through.
Networking, Exchange, Zix, Email, Barracuda,
 

When Microsoft Exchange sends an e-mail, the message size may change due to the encoding used to package it. Messages with attachments can expand even more, since the only way to send e-mail attachments is to convert them from plain ASCII to MIME or UU-encode the message. Even if an attachment is smaller than the limits set in Exchange, it may not be accepted because its MIME-encoded or UU-encoded size is too big. This happens most often when limits are set for inbound SMTP mail. An incoming MIME-encoded e-mail with attachments can increase in size anywhere from 30% to 40%, depending on how many separate attachments, line breaks, MIME headers or other non-data elements are in the message. The exact size can vary enormously, especially since mail systems all behave a little differently when converting e-mail and attachments to MIME. The same problem exists in reverse, where messages sent from your domain will be constrained by message limit sizes on other hosts. Likewise, mail sent from your domain is going to expand anywhere from 30% to 40% in size when converted. [more]

A third-party program, such as UUDeview (http://www.miken.com/uud/), can help you find out just how much larger a MIME or UU-encoded version of a given file will be. (Note that this tool does not calculate things like message size overhead, but it can still be helpful.) The exact maximum incoming and outgoing message size is going to be up to the e-mail administrator, but should be set with these caveats in mind.

Also, take the time to explain to users that when they send attachments, they need to be mindful that messages will increase in size.

Networking, Exchange, Email,
 

I was performing a PST e-mail import task for a migration being done recently.  The user’s PST files were larger than the mailbox quota limits set at 200 MB.  Once the import reached 200 MB of data, it stopped and gave me an error in powershell. 

After examining the quota limit on the mailbox, I increased the size and tried the import again.  It kept failing immediately and the logs showed that the quota limit had been reached. 

After some searching, I found out that there is a waiting period between changing the quota limit and it actually taking effect.  To make the change happen immediately, I found that you can restart the Microsoft Exchange Information Store service, and it will update the quota limits on the mailbox.

Exchange, Email,