Joomla turns anything that looks like an email address into a mailto URL

I spent way too much time today fighting with Joomla trying to turn something off. I need your help - if you know how to do this please let me know and I'll post an update to this article.

The problem is that somewhere in the inner workings of Joomla is some code that looks for anything that looks like an e-mail address, even in preformatted text. I was trying to post an article about troubleshooting e-mail, and I wanted it to leave the test e-mail addresses alone because they are part of the article and are not real e-mail addresses that anyone will want to e-mail.

The problem was even worse because Joomla's editor controls strip out < and > (less than/greater than) symbols in articles that are edited, and replace them with the HTML code &lt; and &gt; I disabled the TinyMCE editor and I was able to save the < and > symbols in the article unharmed. However no matter what I tried, the article as shown in the blog layout and rendered by Joomla to the browser contained mailto URLs. Also, the mailto URLs broke the formatting because somehow the browser or something required a new line before the URL. The < was orphaned in the line above, and the e-mail address was on the next line.

Note that everything was inside <pre>preformat</pre> tags. In my opinion Joomla should not be modifying HTML formatting or adding URLs to anything inside a preformat area.

I worked around the problem by putting &lt;emailaddress&gt; in the code, note the lack of an @ symbol and a dot com. No matter what I tried I couldn't put anything that looked like an actual e-mail address in there, because every time I did it would convert it to a mailto URL like this: This email address is being protected from spambots. You need JavaScript enabled to view it. .  Here it is inside a preformat tag:

<
 This email address is being protected from spambots. You need JavaScript enabled to view it.
 >

As you can see it looks crappy.  As far as I can tell there's no workaround, so if you know the answer to this please feel free to e-mail me and let me know!

Postfix 554 5.7.1 error: Relay access denied from localhost!

I had to troubleshoot a mail relaying problem with postfix. A CentOS6 server had postfix enabled and an application was using "localhost" as its SMTP mail relay. The problem turned out to be the IPv6 address ::1 for localhost. One workaround is to disable ipv6 in the postfix configuration. We did this because this virtual machine has no ipv6 connection so it doesn't matter. The java application that was trying to send mail was throwing this error message:

SEVERE: Failed sending to Someone <emailaddress>
javax.mail.SendFailedException: Invalid Addresses;
  nested exception is:
        com.sun.mail.smtp.SMTPAddressFailedException: 554 5.7.1 <emailaddress>: Relay access denied
        at com.sun.mail.smtp.SMTPTransport.rcptTo(SMTPTransport.java:1862)
        at com.sun.mail.smtp.SMTPTransport.sendMessage(SMTPTransport.java:1118)
        at javax.mail.Transport.send0(Transport.java:195)
        at javax.mail.Transport.send(Transport.java:124)

I tested sending mail through localhost from the command line and it did the same thing:

554 5.7.1 <emailaddress>: Relay access denied

I did the usual googling, looked at a few server fault links, and the consensus seemed to be that the problem was in the smtpd_recipient_restrictions. This was true but didn't directly lead me to the problem. The smtpd_recipient_restrictions were not directly specified in the configuration, but postconf indicated what the setting was:

# postconf | grep smtpd_recipient_restrictions
smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination

So the problem must by mynetworks, right? I looked at mynetworks in main.cf:

# grep ^mynetworks main.cf
mynetworks = 10.0.0.0/8, 127.0.0.0/8

That looks OK too, right? Still no dice on the mail relaying. I looked at the /var/log/maillog and noticed that the logfile indicated the connection was to ipv6 [::1] for localhost:

Jun  5 14:47:52 hostname postfix/smtpd[12148]: connect from localhost[::1]
Jun  5 14:48:01 hostname postfix/smtpd[12148]: NOQUEUE: reject: RCPT from localhost[::1]: 554 5.7.1 <emailaddress>: Relay access denied
Jun  5 14:48:07 hostname postfix/smtpd[12148]: lost connection after RCPT from localhost[::1]
Jun  5 14:48:07 hostname postfix/smtpd[12148]: disconnect from localhost[::1]

Looking at the /etc/hosts (which was still the default CentOS6 hosts file with no changes) I saw that localhost is listed twice, one for IPv4 and one for IPv6:

# cat /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

It would take a sharp eye to catch the connection to ::1 when telnetting to localhost on port 25 to test mail:

# telnet localhost 25
Trying ::1...

I disabled ipv6 in the Postfix configuration by changing inet_protocols in main.cf from all to ipv4, like so:

# grep ^inet_protocols main.cf
inet_protocols = ipv4

Then I restarted postfix. Now when I connect to localhost on port 25 it tries the ipv6 address first but postfix is not listening on the ipv6 address, so that connection is refused. Then telnet retries on the ipv4 address, which is allowed for mail relaying because it's listed in the /etc/postfix/main.cf mynetworks line.

# telnet localhost 25
Trying ::1...
telnet: connect to address ::1: Connection refused
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 hostname.domain.com ESMTP Postfix

Alternatively, if you wanted to leave ipv6 enabled for postfix you could add the ipv6 address for localhost to mynetworks in main.cf.

Netgear CG3000D cable modem keeps resetting

I published a previous blog entry about how my Netgear CG3000D cable modem had apparently failed.  I wrote up a detailed description here about the problem.  That blog entry was mistaken - the modem was fine all along.

I got an experienced Cox technician on site and we came up with what we think is a reasonable explanation for why the modem kept resetting.  Apparently there was some user setting in the NVRAM (flash) which had been saved by a previous version of the modem's firmware.  Cox upgraded the firmware in the background and when the new firmware started up, it read the settings, and found something incompatible.  The Netgear programmers who wrote the firmware decided the best way to handle this situation was to reboot.  As long as the NVRAM contained the same binary string of user settings, this cycle would repeat without ending.

The actual cable modem part was fine, but the router part wasn't able to work with the "corrupt" or incompatible settings.  This is the main problem with integrated cable modem/router combo devices.  If I had a standalone cable modem I would have been able to stay online, and I can just use my wizzy Linux server as the router.  I'm very capable to debug problems with the Linux server.  Not so much with "black box" devices like this Netgear device.

The only way to make the thing stable again was to clear the NVRAM with a full factory reset (hold down the reset pin for 30 seconds, no less than 30 seconds), then wait for it to come back up (the process takes 5+ minutes), then re-enter all the user settings.  I do have to thank the only Tier 2 support person at Cox that I was able to speak with for suggesting this.  Once I realized that the problem had to do with the user settings, it was easy to figure out.

In summary, here is how I got this problem and how to resolve it:

  • The cable modem/router shipped with some firmware version from Netgear.
  • I set several custom user settings for port forwarding, etc., using the original firmware version.  These settings were saved to the NVRAM.
  • Cox upgraded the firmware at some point.  They do this invisibly and in the background and there is no notification or warning or anything. The only way to tell this happened is to check the router frequently to see if it has a new software version number.
  • By the way, the Cox sooper secret login username/password for the Netgear CG3000D router is MSO/changeme.  This information is not really that secret since I found it on a Cox technical support web page.
  • The new firmware apparently has a different "format" or byte-string or something for the arrangement of binary digits (bits) representing the user settings in the NVRAM.  There is no way in their software QA testing that they could try all of the possible combinations of bits that could be in the NVRAM, so this is an honest mistake, but if I was the designer I would have tried to make it backward compatible.
  • When the new firmware was installed it caused a reboot.  On reboot, the firmware read the user settings out of NVRAM and found them to be corrupt.
  • The reboot cycle repeated endlessly until I cleared the NVRAM.

I guess the lesson learned from all this is that I should have tried a "factory reset" of the NVRAM the first time I noticed it rebooting.

The modem is fine and has been online with Cox ever since I resolved the NVRAM issue.  Well it's fine, other than having really crappy (read: generally unusable) wifi hardware.  Most people who have the CG3000D turn off the wifi and use another access point device.

Netgear CG3000D cable modem failure

UPDATE 2! This blog entry is incorrect and has been obsoleted this one: Netgear CG3000D cable modem keeps resetting  Please refer to the updated blog entry for the new, correct information about this problem and how to resolve it.

UPDATE! The brand NEW-IN-BOX Netgear CG3000D cable modem/router that the technician installed yesterday is now doing the exact same thing as the supposedly failed unit!  I guess the problem is something more complicated on Cox's end, and wasn't a cable modem failure after all.  The following is an article I wrote yesterday while I still believed that my original cable modem had failed and the resolution to the problem was to install a new cable modem.  I was wrong about that.  Now I get to call Cox again for more technical support!  (The ticket number is 1542531 for escalation to a higher tier technical support.)

Well I had a lengthy internet service outage that turned out to be a cable modem failure.  This is the first outage of my Cox internet service that could arguably be my fault. I don't know what changed or what failed but the modem was working fine for about 6 months and then last Saturday night I started having a weird problem with my connection.

I have a Netgear CG3000D cable modem+router integrated device connected to Cox cable internet service.  The signals are generally good and are so strong that as a result of one of my previous outages the Cox service technician installed an attenuator to decrease the downlink signal power level which would also cause the modem to boost its uplink signal power.

During this lengthy outage, the modem/router would reset and my internet connection would drop and re-establish itself on a cycle repeating every couple of minutes.  I was running a continuous ping and somewhere between 7-15 pings would get through before it would drop again.  The modem repeated this cycle continuously for hours.  The total outage time was about 2 days - 48 hours!  Here is the sequence of events I observed the Netgear CG3000D cable modem/router continuously repeating:

  • These 6 LEDs were on: power, uplink, downlink, "internet," one of the switch ports, and the wifi LED.
  • The uplink and downlink LEDs would turn blue.
  • All the LEDs would turn off.
  • All the LEDs would flash for a while, then all turn off for a moment. 
  • The power LED would flash for a moment then turn on solid.
  • A moment later (or at the same time?) I think the wifi LED would turn on solid.
  • The downlink LED would flash for a few moments then turn on solid.
  • The uplink LED would flash for a few moments then turn on solid.
  • The internet LED would flash for a few moments then turn on solid.
  • With all 6 LEDs on solid for maybe a minute, the connection would eventually come up and a few pings would get through.
  • Then the uplink and downlink LEDs would turn blue, and this cycle would repeat.

The switch port LED is not really of interest so I didn't mention it much above.  I had an ethernet cable connected to another ethernet switch, but there was no traffic so the light was on solid most of the time.  I think the switch port LED would blink when the other LEDs were flashing but then was on solid after the switch ASIC was initialized.

The internet LED apparently indicates if the router was able to get a DHCP IP address from the network and if network access is allowed.  Generally speaking, if that is on, then you can reasonably expect to have internet access through the router and cable modem, provided your system's networking is set up properly.

 

Read more: Netgear CG3000D cable modem failure

Unreliable Cox Internet Service, and Nagios Flap Detection

I have home internet service from Cox Communications in California.  It's cheap but not very reliable.  I often get random outages and on average once a month theres a really long service outage that lasts from several hours to over a day.  Obviously this is not the sort of internet service you want to run any kind of business on.

However, it's cheap ($30/month) and since I can use Verizon tethering as a backup internet connection I haven't taken the time to find another internet service provider.  However I do want to know whenever this connection goes down and when it comes back up.  I use Nagios for enterprise service and systems monitoring.  Today I discovered that a default setting in my Nagios installation was preventing it from notifying me about service outages.

The Nagios flap detection actually DISABLED notifications of the internet connectivity disruption BECAUSE the internet connectivity was unstable.  This is exactly the opposite of what I wanted to have happen!  Whenever the Cox internet connection drops, I want it to know about it right away (the notifications come to my phone which is on Verizon 4G).  Today I had intermittent disruptions in connectivity and it was so unstable that Nagios actually suppressed notifications!

 

Read more: Unreliable Cox Internet Service, and Nagios Flap Detection