Hackers are Attacking US Gas Pumps

When I worked for Paul Keeshin, at Keeshin Charter Service, between 1985 and 1997, I

Keeshin Charter Service - [1980 -1997]

had the opportunity to work on the "Red Jacket" series of pump controllers and tank monitoring equipment.

The Red Jacket software enabled us to tightly control the amount of fuel that went into our motor coaches and service trucks, preventing theft by drivers who also owned diesel powered trucks. It also tied back into the Versys Charter trip scheduling software, and, based on the

Red Jacket Fueling Systems

the engine operating hours and mileage driven, all entered by the driver or fueler, at the pump, and allocated to the vehicle being fueled at the time of fueling, kept track of vehicle maintenance intervals.

As early as 1989, our computer systems, at all four of our locations, were interconnected.

Versys Charter Management Software

Our main servers were located at 615 W 41st in Chicago, and our O'Hare and McCormick Place offices had access to all of the charter, service work, fuel consumption, maintenance scheduling, maintenance statistics, parts inventory, and lots of other information. During the early 90s, I also made access available via telephone dial-up, and, eventually, the Internet: a feature which allowed incredible growth and gave Keeshin Charter Service a unique edge in our industry at the time.

As part of the software interface, I worked diligently to ensure strong passwords were used: both at an Administrative and user level. I took a bit of heat, from both my co-workers, from the software vendor, and from other users of the software over the fact that I voiced my concerns about security and "back doors". They balked at my insistence on higher than, what were then considered, normal security measures, but we never had an incidence of hacking or inappropriate information access.

Anonymous Takes Credit for Hacking Gas Pumps

Now, because of the fact that so much tech support is being centralized, remotely accessible software security has fallen by the wayside.

Standardized, and default passwords, which make it easier for support personnel to remotely access fueling systems, to troubleshoot or update the software, also allow software allow hackers easy access.

Many of the fueling software systems are easy to get into, because they're still protected by "default" passwords. In other cases, a "standard" password has been established so that any one of up to several hundred techs can remote access software.

Hackers Can Attack US Gas Pumps

Here's a fact, and, yes, it's meant to scare you:

Gas monitoring systems or automated tank gauges (ATG) keep an eye on fuel levels, volume and temperature, among other stats.

When not properly secured, and left unprotected, fuel system software can be manipulated to do something extremely destructive -- like blow up a gas station.

Trend Micro learned about this security breech and decided to do some investigating, and this is what they found out:  "After a gas station monitoring system was hacked earlier this year, Trend Micro researchers Kyle Wilhoit and Stephen Hilt decided to take a closer look. They set up fake internet-connected systems called "GasPots" -- honeypots that mimic the real ones -- in several countries to track hackers' movements.  Turns out gas monitors are never safe: the researchers observed a number of attacks on their GasPots within a period of six months, with US-based ones being the most targeted."

Hilt and Wilhoit discovered more than 1,515 vulnerable gas pump monitoring devices worldwide, less than a third of the figure logged by HD Moore last month.  That would be reason for cautious optimism – except that the duo also uncovered evidence of tampered Guardian AST devices.  The US-located system, left wide open on the net, had been hacked, apparently by mischief-makers, referencing one of ragtag hacker group Anonymous’s favorite catch phrases.

"An attacker had modified one of these pump-monitoring systems in the US. This pump system was found to be internet facing with no implemented security measures.  The pump name was changed from “DIESEL” to 'WE_ARE_LEGION.'  The group Anonymous often uses the slogan 'We Are Legion,' which might shed light on possible attributions of this attack.  But given the nebulous nature of Anonymous, we can’t necessarily attribute this directly to the group. 

An outage of these pump monitoring systems, while not catastrophic, could cause serious data loss and supply chain problems.  For instance, should a volume value be misrepresented as low, a gasoline truck could be dispatched to investigate low tank values.  Empty tank values could also be shown full, resulting in gas stations having no fuel."

The insecure gas pump monitoring system issue is part of the wider problem of insecure SCADA (industrial control) devices.

Start a Ticket

SmarterTech from ChicagoNetTech

Just in case that didn't sink in, let me repeat that: In the case of gasoline monitoring and control software, these default, and standardized passwords potentially allow terrorists to use local gas stations as IEDs (incendiary explosive devices) by overtaking, and overriding, the controls embedded into the same software that allows us to pay for our gasoline at the pump, using our credit cards.

Whether you require assistance securing your fuel dispensing systems, patient data, financial data, or your computer network, give me a call (773-365-0105), or open a ticket at https://portal.chicagonettech.com/Main/frmNewTicket.aspx (registration required).

With more than 35 years of experience, we'll help vet any hidden issues and secure your data - before it becomes an explosive situation.

Copyright © ChicagoNetTech Inc, 2015. All rights reserved.

SRS Header Rewrites Broken in Many E-Mail Servers - Causing "550" Errors

While the content of this message is specifically applicable to the SmarterTools, SmarterMail e-mail server product, it is of extreme importance to everyone who uses or hosts their own e-mail.

It turns out that, since sometime around SmarterMail version 10.X or 11.X, the ability of SmarterMail to properly do something called SENDER HEADER REWRITE has not been functioning properly and this is causing 550 NON DELIVERABLE ERRORS on e-mail which is FORWARDED from someone's SmarterMail account.

 

For those of us who are involved, on a day-to-day basis with e-mail services, and troubleshooting those services, this has been a thorn in our sides since OUTLOOK.COM, YAHOO!, GMAIL, COMCAST, and many other e-mail providers, ChicagoNetTech included, have enforced DMARC and other antispam protocols in an effort to keep our user's in boxes as fee of spam as possible.


 

For those who have been sending e-mail and seeing 550 X.X.X errors which specify that their e-mail was not delivered because of an SMTP AUTHENTICATION ERROR, along with the techs who have been attempting to troubleshoot these non-delivery issues, this has been an absolute nightmare, to all of whom who have so suffered, I sincerely apologize.

Some background:



 

In our efforts to prevent spam from being forwarded via an unauthorized source, many ISPs are now performing hard checks SMTP + SPF | Protected by SPFon all incoming messages to ensure that the SPF included in the message header actually matches the SPF information for the domain which is forwarding the message.


 

When someone has their e-mail setup to FORWARD to another account, unless SRS has been enabled by the relaying MX server, the SPF no longer matches the original sender's MX to SPF mappings and the messages are now frequently rejected by the receiving MX server.  This is now being enforced by Gmail, YAHOO! and COMCAST, as well as ChicagoNetTech, as we look for additional ways to prevent spammers from "gaming the system" and they continue to find new ways to work-around and circumvent the latest spam prevention techniques.

While this is almost always an inconvenient incumbrance to the party who's forwarded e-mail is rejected, after being forwarded, most modern MX servers have a way to insert updated header information into the message, leaving the original headers intact, and adding routing information to the message header so those MX servers receiving forwarded messages will not reject the forwarded message.

In SmarterMail, this is easily enabled by the primary MX server administrator by ENABLING SRS to REWRITE the MESSAGE HEADER as it passes through the SmarterMail MX server.

 

Is There Anything Else to the Equation?

In February, 2013, a new player was introduced to the antispam field.  Called DMARC, this tool is designed to allow e-mail server operators to tell those e-mail servers who respect the DMARC protocol what to do with messages which originate from sources other than authorized e-mail servers.  The immediate effect of the DMARC protocol was that it almost completely eliminated job-jobbing, a form of e-mail spoofing which usually caused major headaches for the sender who's e-mail address had been hijacked as the "reply to" address on bogus e-mail messages.

DMARC checks for valid:

 

      DomainKeys: a private certificate, generated specifically for a domain, and mapped to the domain both in the messages header and in the domain's DNS, which validates the ability of that domain to originate an e-mail message;

      DKIM Records: digital signing of specific fields of a message, tied to the DomainKey of the domain from which the message was sent;

      SPF Records: Sender Policy Framework records were one of the original tools adopted to ensure the authenticity of messages and a very early form of authentication which tied IP addresses and domains together;

      rDNS or IN-ARPA Records: a reverse address mapping of the IP Address from which the message was sent to the Fully Qualified Domain Name (FQDN) of the e-mail server with the authority to originate a message on behalf of a domain. 

 

 

 

Because DMARC is a flexible protocol, designed to allow e-mail server operators the capability to gradually "turn up the heat" on spam messages received at receiving e-mail servers, an issue with message forwarding was not readily apparent, until about a year ago, when GMAIL turned up the head and started to completely restrict messages which did not absolutely meet the DMARC protocol.

So, How is SRS Rewrite Supposed to Work? 

With that in mind, let's go back and look at how SRS Header Rewrites are supposed to work.

In traditional, or verbatim, forwarding, the return-path is preserved in the outgoing message.  Here's a graphic to help illustrate the issue:

Forward WITHOUT SRS Forwarding: Header Rewrite - will fail

and here's a graphic with the SRS rewrite added - allowing the message to pass SPF when received at the new mailbox 

Forward WITH SRS Forwarding: Header Rewrite - will PASS

In an SPF world, forwarders need to rewrite the return-path to stay in good standing.  

The SRS library implementations help perform the needed transformation and ensure proper delivery.  Full-time forwarding services may prefer to integrate this logic directly into their MTAs.  Smaller sites don't have to: they can just call the srs utility which does all the work.

Once you have enabled SRS, additional header information will be written into the header of the original message, allowing it to meet the SPF compliance for the SmarterMail server which is forwarding, or RE-SENDING the message to the party's off-site e-mail address, without the receiving MX server rejecting the message for an SPF error. 

When the full force of DMARC is applied, and an SPF error occurs because of a failed SRS header rewrite scenario, we end up with what is referred to as a 550 ERROR

But wait, the 550 ERROR message says that the message was rejected because the sender did not use SMTP AUTHENTICATION, and that's something that's commonly checked as part of the antispam measures, to prevent spam from reaching all of our in boxes, right?

Yes, but the 550 ERROR is also the error which is returned with there is a MISMATCH on the SENDING E-MAIL ADDRESS DOMAIN because it is not included in the SPF RECORD!

 

Pictures are Sometimes Very Helpful!

Here's a picture which might help you understand the issue better:

 

Point of information:  an MTA is another way to reference an e-mail server.

So, the ORIGINAL MTA sends the message to the RECEIVING MTA. 

The receiving MTA then validates all of the informaiton in the message header against a REMOTE MTA, generally a DNS SERVER, which contains information on what server is responsible for what kinds of services for a specific domain name and its services, and then reports back to the REPORTING MTA whether the information contained in the message headers is GOOD or BAD.

When the SRS header is not properly rewriteen, the REMOTE MTA reports back to the REPORTING MTA as BAD DATA and the REPORTING MTA rejects the message, via the RECIVING MTA with a 550 ERROR.

 

 

 

 

 

The receiving e-mail server is rejecting a legitimately forwarded e-mail message because it thinks it is from a spammer, IE: the SENDING DOMAIN is not authorized, under SPF, to send on behalf of the domain which actually sent the message

It turns out the 550 ERRORS are NOT a spam issue, but a FORWARDING ISSUE -- a FORWARDING ISSUE which is caused by the fact that SRS HEADER REWRITES were not properly written into the message header (a part of every e-mail message which tells the receiving e-mail server where it came from, who sent it, how the recipient should reply, etc, and also contains important routing and antispam information.

 

Summary:

The messages are being rejected because SmarterMail, along with many other MX servers, is not properly doing a SRS FORWARD HEADER REWRITE and the messages appear to be SPAM which was sent through an OPEN RELAY.

I've opened a ticket with our SmarterMail vendor, SmarterTools.  You can read the ticket, comments, and progress, at: https://portal.smartertools.com/community/a2676/srs-header-rewrite-not-working-properly-on-message-forwarding-_-_-_.aspx

You can also see my original KB (Knowledge Base) article on SRS Forwarding at: https://portal.chicagonettech.com/kb/a177/enable-srs-to-prevent-spf-fail-on-forwarded-e-mail-messages.aspx

While this particular instance relates to a software problem with a specific product, SmarterMail, this is not an uncommon situation with e-mail servers, which are also known as MX servers and MTAs.

If you have experienced issues with 550 errors and e-mail rejection, you may want to forward this e-mail to your IT Department or e-mail support group so they can look into whether their e-mail server product is properly inserting SRS Header Rewrites into e-mail message headers.

Remember, ChicagoNetTech provides secure e-mail and web hosting services and will be glad to help you make your online experience better.

Bruce Barnes ஃ

ChicagoNetTech Inc

SmarterTools Product Specialist
E-Mail and DNS Security Specialist
Network Security Specialist

Web: https://www.ChicagoNetTech.com
Customer Service Portal: https://portal.chicagonettech.com

FaceBook: https://www.FaceBook.com/chicagonettech

LinkedIN: https://www.linkedin.com/in/chicagonettech
Blog: http://networkbastion.blogspot.com/
Mobile APP: ChicagoNetTech via Google Play

ChicagoNetTech uses tools from SmarterTools, including SmarterMail, SmarterStats, and SmarterTrack to provide the best possible customer service at the lowest possible rates.

"Nam et ipsa scientia potestas est" "Knowledge is power" - Francis Bacon (1561—1626)

"Only the paranoid survive." - Intel Founder - Andy Grove (1936 - )

USPS Employee Portal Hit by Massive Hack!

The list of network hacks continues to grow, with the latest hack being the employee portal of the USPS. That's story is located at: http://www.cnn.com/2014/11/10/politics/postal-service-security-breach/index.html

What's even more interesting, however, is that fact that the USPS has still not properly encrypted their Employee Portal at:https://ereassign.usps.com/ereassign/login/welcomeEmployee.pge - it's still vulnerable to Poodle and other SSL v3.0 attacks.

Here's a site which will show you their SSL Certificate results in real time:https://www.ssllabs.com/ssltest/analyze.html?d=ereassign.usps.com&hideResults=on

The fix is actually very easy for anyone running Server, 2003, Server 2008, or Server 2012. For both the how to, and the necessary REG files, see my documents at: 

https://portal.chicagonettech.com/kb/c20/mailserver-security.aspx

---

Bruce Barnes, owner of ChicagoNetTech is an active member of the SmarterTools online support team who's posts can be found on the SmarterTools Technical Support Forums.

ChicagoNetTech's support portal is located at https://portal.chicagonettech.com 

Wall Street Journal Hacked

Another major publisher's networks and web services have been hacked.


According to published reports from The Wall Street Journal, their news graphics computer network has been hacked.

The WSJ reports that no damage has been done to their graphics systems and also went on to say that they believe customer data remains safe, but then went on to say that they have retained the services of IntelCrawler, a Los Angeles-based cybersecurity firm, who brought the hack to their attention.

The hacker, who calls himself "w0rm," alleges to have founded Worm.in: an online market for trading cyber vulnerabilities. 

w0rm is threatening to sell both user information and the credentials required to control the Journal's servers, and is offering user credentials and the information required to control the server. According to a tweet, which contained an alleged screen capture from the WSJ's server database, w0rm is offering access for payment in one Bitcoin: approximately $620 at the time of writing.





If w0rm has achieved the kind of capability he claims, he could, potentially, modify articles, adding new web content, and insert malicious content in pages hosted at the WSJ website.  He could potentially add and delete site users as well. 


Andrew Komarov, chief executive of IntelCrawler, explained that his team initially discovered the vulnerability used by the hacker and confirmed that it could give an attacker the access claimed.  Komarov added his firm has been monitoring w0rm for some time.


If you're a subscriber of the Wall Street Journal's online edition, this might be a good time to change your wsj.com password.


For information on selecting a strong password, check out, "Passwords, the Bane of Any IT Manager"

---

Bruce Barnes, owner of ChicagoNetTech, is an active member of the SmarterTools online support team who's posts can be found on the SmarterTools Technical Support Forums.

ChicagoNetTech Announces New Customer Service Portal

ChicagoNetTech has unveiled a new customer service portal for our customers at http://portal.chicagonettech.com.


The new portal, which runs under SmarterTools SmarterTrack CRM software will allow ChicagoNetTech to better track and serve the requirements of our customers, provide better service and give us better history on issues which have been resolved.


The new CRM portal has a fully searchable knowledge base which contains self-help articles on setting up smartphones, tablets, and desktop software with our SmarterMail e-mail server software; technical support articles on network and e-mail security; and other articles of interest to our customers.



If you're looking for reliable web and e-mail hosting, with good, old fashioned customer service, check out our website and give us a call.  We'll be happy to work with you to show you what US based servers, techs and customer service can do for your business!

---

Bruce Barnes, owner of ChicagoNetTech is an active member of the SmarterTools online support team who's posts can be found on the SmarterTools Technical Support Forums.

Why Am I Having Problems Getting My E-Mail Delivered?

One of the most frustrating issues facing any e-mail [MX] server operator is non-delivery of e-mail!

 

As ISPs, none of us wants to hear from a customer who is having issues trying to send e-mail, but, the unfortunate fact is more and more of our customers are encountering non-delivery issues and they can be extremely difficult to troubleshoot.

 

There are many reasons an e-mail message might not be delivered, including, but not limited to:

• bad e-mail addresses;
• forgotten passwords;
• having a user's domain or account listed as a source of spam;
• being blocked by the recipient - especially common with AOL users

Here are some of the other common causes of temporary non-delivery issues:

• design - to help prevent spammers from flooding everyone's mailbox with junk mail and spam;
• network congestion - sometimes the networks which carry the data are extremely busy and alternative routing is not available;
• technical issues - sometimes the DNS servers, the master databases which tell all of the other servers using the Internet where everyone is supposed to be located have become corrupted or unreachable;
• software issues - sometimes the software on the other end is non-responsive;
• DDoS attacks - sometimes the receiving e-mail server is bogged down because it is under a "Distributed Denial of Service" attack.  DDoS attacks are extreme situations where someone has illegally targeted a server or network appliance in an attempt to hack or take that machine out of service and can cause major, and sometimes extended, delivery delays;
• hardware issues - sometimes the hardware on the receiving end is in trouble or is undergoing maintenance

If the message was rejected by the receiving MX server you should receive a reason code for the rejection.

 

These delivery codes are based on the Extended SMTP (ESMTP) standards, where X can be 4 or 5, depending on the error type (Persistent Transient or Permanent).

 

Here's a summary of those codes:

• X.1.0 Other address status
• X.1.1 Bad destination mailbox address
• X.2.0 Bad destination system address
• X.1.3 Bad destination mailbox address syntax
• X.1.4 Destination mailbox address ambiguous
• X.1.5 Destination mailbox address valid
• X.1.6 Mailbox has moved
• X.1.7 Bad sender's mailbox address syntax
• X.1.8 Bad sender's system address
   
• X.2.0 Other or undefined mailbox status
• X.2.1 Mailbox disabled, not accepting messages
• X.2.2 Mailbox full
• X.2.3 Message length exceeds administrative limit.
• X.2.4 Mailing list expansion problem
   
• X.3.0 Other or undefined mail system status
• X.3.1 Mail system full
• X.3.2 System not accepting network messages
• X.3.3 System not capable of selected features
• X.3.4 Message too big for system
   
• X.4.0 Other or undefined network or routing status
• X.4.1 No answer from host
• X.4.2 Bad connection
• X.4.3 Routing server failure
• X.4.4 Unable to route
• X.4.5 Network congestion
• X.4.6 Routing loop detected
• X.4.7 Delivery time expired
   
• X.5.0 Other or undefined protocol status
• X.5.1 Invalid command
• X.5.2 Syntax error
• X.5.3 Too many recipients
• X.5.4 Invalid command arguments
• X.5.5 Wrong protocol version
   
• X.6.0 Other or undefined media error
• X.6.1 Media not supported
• X.6.2 Conversion required and prohibited
• X.6.3 Conversion required but not supported
• X.6.4 Conversion with loss performed
• X.6.5 Conversion failed
   
• X.7.0 Other or undefined security status
• X.7.1 Delivery not authorized, message refused
• X.7.2 Mailing list expansion prohibited
• X.7.3 Security conversion required but not possible
• X.7.4 Security features not supported
• X.7.5 Cryptographic failure
• X.7.6 Cryptographic algorithm not supported
• X.7.7 Message integrity failure

As of January, 2013, there's a new reason your customer's e-mail might not be delivered, and many MX operators are not aware of it.  This document will not only help you figure out why you are having issues with e-mail delivery, but will also assist you in ensuring that future e-mail is properly delivered.

 

TO WIT:
 

YAHOO!, Comcast, Google, Hotmail and many other large ISPs adopted new measures to help prevent spam from being delivered to user's in boxes.

 

When you factor these measures in with the requirements of the US CAN SPAM ACT of 2003, and also factor in the European Can Spam Act [which we must, by default, both recognize and abide by in the US because all BLACKBERRY devices use SMTP servers in Vancouver BC Canada; Canada is under British rule and Great Britain is part of the European Union], mailing list management can begin to get really complicated.
 

Based on my experience with YAHOO!, AOL, GMAIL and COMCAST - now the LARGEST ISP in the United States and processes more e-mail than anyone else in the US - and based on the rules, which were put into place by those two operators in January, 2013, these are requirements which should be put into place by every MX server operator:

When you factor these measures with the US CAN SPAM ACT of 2003, and also factor in the European Can Spam Act [which we must, by default, both recognize and abide by in the US because all BLACKBERRY devices which directly access Blackberry e-mail systems use SMTP servers in Vancouver BC Canada; with Canada being under British rule, and Great Britain being a part of the European Union], mailing list management can begin to get really complicated.

Canada's antispam law kicks in on 1 July, 2014
 

Here are a few of the basic requirements which must be implemented to ensure you are in compliance with the new requirements set forth by YAHOO! and COMCAST.

 

By following these requirements you will also be in compliance with all of the other large ISPs:
 

1. Make certain you are in full compliance of ALL THREE can spam acts with every e-mail which leaves your e-mail servers.
    
2. While you and your customers may believe the destination of their e-mail is a US based e-mail account, Internet data can cross international borders without our knowledge.  Once that data crosses a country's border, it is subject to that country's regulations.
   
   Here are links to the three major CAN SPAM ACTS:
    
   1. US CAN SPAM ACT of 2003;
       
   2. European Can Spam Act;
       
   3. Canada's antispam law
       
3. Make certain PORT 587 is OPEN on ALL MAIL SERVERS.
    
   1. The IETF, under RFC 5068, has now PROHIBITED providers from blocking port 587.
       
   2. RFC 5068 clearly says: "Access Providers MUST NOT block users from accessing the external Internet using the SUBMISSION port 587."
       
   3. The complete RFC is available here: http://tools.ietf.org/html/rfc5068
       
4. Make certain you have received ADVANCE PERMISSION from everyone who is on your mailing list in the form of DOUBLE OPT IN.  Because of requirements contained in the European Can Spam Act, it is no longer acceptable to add an address because you have done business with them.
    
5. In any SIGN-UP forms DO NOT ADVANCE CHECK the OPT-IN BOX.
    
   1. The OPT-IN box MUST be SELECTED or COMPLETED by the INDIVIDUAL who might be interested in signing up for an e-mail list.
       
   2. EU regulations prohibit the pre-completion or pre-selection of any field in a newsletter or mailing list sign-up form.
       
   3. Contrary to US antispam regulations, the EU mandate includes those who purchase items from online stores.  They must ACTIVELY INITIATE the SIGN ME UP process by either CHECKING A BOX or ENTERING THEIR E-MAIL ADDRESS into a box - you cannot pre-populate that data.
       
   4. Even though someone makes a purchase from a website, they must still complete the double-opt-in process described below.
       
      1. All sign-ups must include a follow-up e-mail which forces the customer or person signing up for the list to actively complete the DOUBLE-OPT-IN step.
         
         IE: The customer must MAKE THE CHOICE a SECOND TIME to validate their initial sign-up process for the list.
          
      2. To see an example of how this works, go to http://www.chicagonettech.com/subscribenewsletter.asp, and enter your e-mail address.
          
      3. In a few minutes, you will receive a request to CONFIRM your subscription request.
          
      4. Once you click on the link, you will be added.  If you do not complete the confirmation step, you will not be added to the list.
          
      5. NOTE: This is entirely handled by our SmarterMail e-mail server's list serve package which is standard in the Enterprise edition of the software.
          
      6. An alternative to using the SmarterMail list server is to use CONSTANT CONTACT, MAIL CHIMP or one of the other third-party services which provide bulk mailing services and automatically include double-opt-in as part of their sign-up process.
          
      7. Should you choose to use a 3^rd party bulk mailing service, you MUST also include the appropriate SPF INCLUDE statement in your SPF record so bulk messages sent on behalf of any of your hosted domains which choose to use the external bulk mailing services are not rejected because the proper SPF information is not included.
          
6. Make certain you have a VISIBLE, PUBLIC, WORKING PRIVACY PAGE posted on each website which has a domain hosted on your MX server.
   
   YAHOO will actively VERIFY THIS via a human being who will actually open and read your privacy page before they will approve you for the FEEDBACK LOOP [see Item #11 below for more information on Feedback Loops].
   
   See our privacy policy at: http://www.chicagonettech.com/privacy.asp as a sample page and feel free to copy it if you do not already have one.
    
7. All bulk list, sales, and promotional messages must include complete contact information, including: a mailing address and unsubscribe link.
    
8. Make certain ALL e-mail is sent via an AUTHENTICATED E-MAIL ACCOUNT.  Do NOT send e-mail directly to a recipient from a webpage, form or shopping cart.  Instead, setup the form, website or shopping cart to use a designated e-mail address to AUTHENTICATE with your MX server and send the message THROUGH the MX server.
   
   This may mean going back and revisiting the code in some web pages, but it must be done because messages which are not authenticated will be treated like spam and rejected by many MX servers.
   
   OBSERVATIONS:
    
   1. In spite of the inclusion of that information, most AOL users will still report you as SPAM and fail to unsubscribe from your lists.  That's where the FEEDBACK loops come in.
       
   2. The feedback loops will mostly protect you from the brainless AOL users because you will be notified and, if you have properly included an unsubscribe link in the message, will be able to open the attachment and click on the unsubscribe link to remove the brainless user from future mailings.
       
9. Make certain you IMMEDIATELY REMOVE someone from the list if they request such an action - an automated removal format is preferred.
   
   REMEMBER: all AUTO-GENERATED and COMMERCIAL e-mail messages must contain a WORKING opt-out link.
   
   NOTE: You are NOT ALLOWED to require any kind of input or reason in the removal form.
   
   NOTE: You should attempt to auto-populate the e-mail address requesting removal in the removal form, if possible, and CANNOT enforce a removal reason to be entered as part of the removal request.  You can ask that they provide a removal reason, but cannot deny removal because someone refuses to enter a reason.
    
10. You [your hosted customers] MUST AUTO-REMOVE ALL bouncing e-mail addresses.  We auto-remove all users after a list or newsletter bounces 3 or more times.  Again, our MX server package, SmarterMail, takes care of this automatically.
     
11. Make certain you have setup FEEDBACK LOOPS with all of the major providers.  The setup of these loops can be effected via Henry's UNLOCKTHEINBOX.com website and will require a login to the site to complete.

10. Make certain ALL OUTGOING MESSAGES are AUTHENTICATED VIA SMTP.
     
    1. Do not send directly from a web form or newsletter generator.
        
    2. While it is OK to generate a message via a website, or generate a newsletter via a website, you MUST use SMTP AUTHENTICATION to SEND the generated message or sales receipt THROUCH AN MX SERVER using a VALID E-MAIL ADDRESS and PASSWORD from the DOMAIN which corresponds to the WEBSITE or other message generator because sending via an SMTP AUTHENTICATED account will properly created HEADERS in EVERY OUTBOUND MESSAGE!
        
11. Use rDNS, SPF, 2048 BIT DOMANKEYS, DKIM, and DMARC on ALL OUTGOING MESSAGES.  The first five are now REQUIRED by COMCAST and YAHOO!  DMARC is optional, but strongly suggested.
     
12. DMARC is a logical addition [see http://www.dmarc.org/ or see the DMARC information at http://www.unlocktheinbox.com/] because it truly locks down where your e-mail can be sent from and will literally block delivery of unauthorized messages originating from non-authorized MX servers and user accounts
    .
13. Do not omit the SPF and rDNS keys, most large ISPs, and many smaller ISPs as well, will never even accept your e-mail.  The receiving MX server will simply drop the connection and never allow the message to be received – without any notification to you.
     
14. Remember, GREYLISTING is now commonly used to help reduce spam.
     
    1. In order to make certain you are not contributing to Greylisting problems, make certain you RETRY messages which are not delivered the first attempt.
       
       ChicagoNetTech’s SmarterMail RETRY times are set as follows:
       
       [in minutes]: 5, 5, 15, 30, 30, 30, 30, 60, 90, 120, 240, 480, 960, 1440, 2880
        
    2. Trying more frequently during the first few attempts will probably result in your MX server being blocked by the receiving server.
        
    3. This retry schedule shown above will ensure that the IETF requirement of attempting to resend e-mail for UP TO FIVE DAYS is enforced.
        
    4. The number of retries is based on RFC 2821.4.5.4.1, which defines SMTP retry intervals and says, "Retries continue until the message is transmitted or the sender gives up; the give-up time generally needs to be at least 4-5 days."
        
    5. We allow messages to come through greylisting after 2 minutes and list the sender in our non-Greylisted database for 144 days after the initial successful delivery attempt.
        
    6. Many ISPs still have a 15 minute initial greylisting time established, so don't lose out on potential messages which are never delivered because of greylisting.

 

SUMMARY:  E-Mail is no longer just an “add-on” which is included with a webhosting package as a convenience for our customers.

 

E-Mail must be constantly monitored and a good ISP / MX operator is cognizant of what’s going on in his or her network and e-mail servers at all times.

 

Whether you’re confused or just need some help deciphering and implementing these new requirements, get in touch with us and we’ll be glad to help you out.

 

Just open a ticket with us and ChicagoNetTech will be glad to take a look at your SmarterMail or other e-mail server and help you sort things out.  If you don't already have an account on our Customer Service Portal, you'll need to create one prior to opening your new ticket.

 

Licensed SmarterMail software owners get a 35% discount over our standard rates when they require updates, troubleshooting, configuration, or any other SmarterMail server and/or maintenance assistance.

We can work on a case-by-case basis or on a monthly maintenance retainer with a level of support and/or service set by agreement with us and you.

Please setup an account and open a ticket or contact us via our contact form for more information on how we can turn your already great product into a minimum of maintenance and headaches.

 

Don’t forget to search our KB [knowledge base] for solutions to other problems and issues you might have encountered, too.

 

ChicagoNetTech's hosting and technical support rates are reasonable and we accept all major credit cards via PayPal.

For references and examples of my support of SmarterMail, please see my entries at: http://forums.smartertools.com/members/chicagonettech.7401/, where I have accumulated more than 3,550 support conversations since 2007.
 

Additional references upon request.

 

Copyright 2013 - 2014, ChicagoNetTech Inc, All Rights Reserved

1024 Bit Encryption Depreciated!

Editor's Note: This is a reprint of an article which I originally published on the SmarterMail technical support forum on 22 August, 2012.  It has been republished, both here, and in my ChicagoNetTech Knowledge Base, because I still run into situations where a customer is totally unaware of the fact that all 1024 bit SSL certificates have been retired.


Given recent certificate and SSL security hacking issues, it is important that this information be pushed out to as many server and web services operators as possible.

---

Until the recently, the RSA algorithm, first publically described in 1977 has been the only algorithm available for commercial digital signing certificates. The RSA algorithm remains the de facto standard although commercial certificates based on the DSA and ECC algorithms are now available.

 Simply put: The larger the certificate key size in an RSA certificate, the more difficult it is to compromise the encryption.

As raw computing power increases over time it becomes possible to factor or crack smaller sized RSA keys. Key sizes smaller than 1024 bits were voluntarily discontinued by Microsoft on 12 December, 2012.

Seventeen RSA key sizes have been factored since 1991. Most recently most of the industry has standardized on certificates with 1024-bit RSA keys. However, industry experts warn that the oft used 1024-bit RSA key size is now at risk of being compromised by cyber criminals.

As a proactive measure, effective 31 December, 2013, the NATIONAL INSTITUTE OF STANDARDS and TECHNOLOGY [NIST] recommended that 1024-bit RSA certificates be eliminated and replaced with 2048-bit or stronger keys.

As a result of the NIST recommendation, the Certification Authority/ Browser (CA/B) Forum, created to develop best practices within the SSL/TLS industry, created a mandate to bring the 1024-bit RSA key size to end of life by December 31st, 2013.

The Responsibility of a CA

All responsible Certificate Authorities (CAs) should have their customer base of this regulation change and assisted them with their migration to a more secure keysize.  

Due to the industry’s end-of-life mandate on 1024-bit certificates, Certification Authorities have the difficult requirement to revoke 1024-bit RSA certificates that expire after 12/31/13.




If you have an SSL certificate which was issued by a CA, and have not been contacted by them regarding issues with either your PRIMARY or SECONDARY SSL certificates, you should open an inquiry with the issuing CA as quickly as possible to prevent possible intrusion into your networks and systems.


If you believe you have issues with non-complient SSL certificates, you should immediately contact the issuer of your SSL certificate, you should immediately contact the issuer of your SSL certificate and ask them to ensure that both your primary and secondary SSL certificates are at least 2048 bit certificates.

What Does This Mean?

As a result of these changes, mandated by NIST, all current CERTS with a key size of 1024 bits or less than bits should have been replaced by 31 December, 2013, or users of smaller certs will run the risk of having them denied when they are checked in situations where they are used for encryptions.  The minimum recommended SSL certificate length is now 2048 bits.

For More Information:

• NIST Special Publication 800-131A | Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths | http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf
• - Comodo 2048 bit SSL Certificates | http://www.incommon.org/certificates/doc/2048-bit-Certificates.pdf
• - Symantec | 1024-Bit Migration Informational Webinar | http://www.slideshare.net/NortonSecuredUK/1024-deck-may-2013

---

Bruce Barnes, owner of ChicagoNetTech is an active member of the SmarterTools online support team who's posts can be found on the SmarterTools Technical Support Forums.

Checkout the new ChicagoNetTech APP at: m.chicagonettech.com