Reporting bugs in the new siteware.

Status
Not open for further replies.
Nope that didn't work but someone with a bit more mx / DNS etc knowledge may be able to confirm if this is the issue ?

electro-tech-online.com resolves to electro-tech-online.com (141.101.126.102)
www.electro-tech-online.com resolves to www.electro-tech-online.com (141.101.125.102)

>set type=mx
> electro-tech-online.com
Server: google-public-dns-a.google.com
Address: 8.8.8.8

Non-authoritative answer:
electro-tech-online.com MX preference = 10, mail exchanger = dc-3cb7bdbe.electro-tech-online.com


So the mail server is at dc-3cb7bdbe.electro-tech-online.com
Pinging dc-3cb7bdbe.electro-tech-online.com [68.233.249.134]

So two different IP addresses but is the mail sender from electro-tech confusing the email recipient software by just saying the mail is coming from electro-tech-online.com rather than dc-3cb7bdbe.electro-tech-online.com ?

It could also just be an incompatibility between this version of Postfix and the electro-tech notification mailer but I'd say 95% of all errors in my logs are from electro-tech-online.com
 
It's not even getting the message through to my server looking at the logs. My server is set to accept all by default (apart from viruses) and just tag spam with a spam tag.

I'll try whitelisting electro-tech but I doubt it is going to make any difference.
 
Whitelisting on the server has not produced any results - I'll try it by IP address but again not hopeful.
Code:
Nov 11 20:32:02 pbhpx postfix/anvil[19047]: statistics: max connection rate 3/60s for (smtp:68.233.249.134) at Nov 11 20:27:03
Nov 11 20:32:02 pbhpx postfix/anvil[19047]: statistics: max connection count 5 for (smtp:68.233.249.134) at Nov 11 20:27:03
Nov 11 20:32:02 pbhpx postfix/anvil[19047]: statistics: max message rate 3/60s for (smtp:68.233.249.134) at Nov 11 20:27:03
Nov 11 20:32:02 pbhpx postfix/anvil[19047]: statistics: max cache size 2 at Nov 11 20:28:17
Nov 11 20:32:03 pbhpx postfix/smtpd[19170]: timeout after DATA (0 bytes) from unknown[68.233.249.134]
Nov 11 20:32:03 pbhpx postfix/smtpd[19170]: disconnect from unknown[68.233.249.134]
Nov 11 20:32:03 pbhpx postfix/smtpd[19169]: timeout after DATA (0 bytes) from unknown[68.233.249.134]
Nov 11 20:32:03 pbhpx postfix/smtpd[19169]: disconnect from unknown[68.233.249.134]
Nov 11 20:32:03 pbhpx postfix/smtpd[19171]: timeout after DATA (0 bytes) from unknown[68.233.249.134]
Nov 11 20:32:03 pbhpx postfix/smtpd[19171]: disconnect from unknown[68.233.249.134]
 
Ok - I'm 99% certain I've found the problem. My gateway has a MTU setting of 1492 while my email server had an MTU setting of 1500. While 99% of email was getting though without a problem, the server at electro-tech really didn't like the MTU mismatch and spat its dummy out.

I've aligned both the MTU on my email server with my gateway and I've had my first emails through in ages !
 
Mine was set to 1500, which is default for current Netgear and my FIOS provider (Armstrong). However, neither computer on either network is receiving ETO emails. I changed absolutely nothing on the other computer in the past year. It just stopped getting them a month ago or so.

John
 
Progress, but I am still in the woods.

Following MS's and Netgear instructions, I find that my MTU's should be set at 1500, and when I ping ETO at 68.233.249.134 with 1500 bytes, I get the "packet needs to be fragmented but DF set" error. Ping with 1492 gives the same error, but 1472 (1500 -28 per MS) comes back. I neglected to write down the times.

So, is ETO set at 1472, or is there some setting in my system that I am not finding?

John

Edit:
Here are the ping results:


And just FYI, here are the network MTU settings. I don't understand the LAN response, but everything, except ETO, seems to work OK, including a wireless printer.

 
Last edited:
If you're not running your own email server then you shouldn't need to do anything with the MTU on your router or computer.

To find your correct MTU setting, you keep reducing the packet size you're pinging with until it works without fragmenting then add 28 to that value.

In my case, as I run my own email and web servers, my Router had the MTU set to 1492 but the server had the MTU set at 1500. Googling some of the more obscure error messages I was getting from ETO mail on my server led me to a group where people were having Postfix issues with timeouts and by setting the server to the same MTU as the router it resolved the problems.

It appears that only a few incoming messages were affected. Some spammers couldn't get through, ETO had major issues and some but not all Facebook notifications occasionally got delayed.

I'm not sure if changing the MTU on the electro-tech email servers would make a difference but those who are having issues receiving emails may wish to ask their ISP / email provider if there is a possible issue at their end - there will be plenty of stuff in the logs from ETO if there is.
 
Like I said, I am still in the woods. My testing was the direct result of an MS response to a Windows Live Mail user who was having problems with WLM disconnecting. Its advice was to ping at various packet sizes, find one that worked, then set his local MTU to that size -- not that size + 28. Author was Gerald_G, a Microsoft Forum moderator.

The part of the problem I am having that baffles me is that the failure to get notices happened simultaneously on two e-mail accounts running different email software with different OS's (WLM with Win7 and Outlook Express with XP Pro) on two different machines. Each machine was connected to a different ISP (Armstrong, Cox), and the locations are 42 miles apart. It not only affected the e-mails forwarded to the local machines, there is no trace of anything on the corresponding Webmail accounts.

I will call at least one of the providers today and see if it will look in the logs.

John
 
Already contacted one of the ISP's. That level of service is not available until after 0700 EST USA. Will post a follow-up.

John
 
The chat above is fascinating, but way over my head. Just thought I'd add my 2p by saying that I set my profile to receive email notifications of posts on this thread but I'm not receiving them.
 
I did get through to Armstrong, and it is running a log. Hopefully, that will be sometime today.

@EM: Can you confirm which of the IP addresses Picbits found should be used for the log? I gave the ISP both 68.233.249.134 and 141.101.126.102 as well as the name.

BTW, I pinged the second address too, and that worked fine.

John
 
The 68.233 address is what your mail server should see - this is the one that delivered the ETO mail. The 141.101 address gets you to this site.
 
Just heard from Armstrong. It uses Spamhaus.org, and 68.233...is listed:


Maybe a solution is near? According to the tech service person, getting off the list will require an action by EM.

If this solves the problem, maybe weekly maintenance (or more frequently) should include checking blacklist providers.

John
 
Hi Guys, I've requested the removal and am looking into why we were originally listed. It should take 1 hour to be processed.
 
Last edited:
Here's an update. Apparently it is been removed from the CBL list:
**broken link removed**

ETO was also listed on spamcop.net and will be de-listed in about 19 hours, according to that site.

John
 
I am happy to report that I just got 7 e-mail notifications on the service that used Spamhaus.org (Armstrong). Its MTU is set at 1500 according to the agent, BTW.

Believe it or not, when I called Cox Communications, I got stonewalled on the question. A few years back, there was a similar problem with a forum being on the Cox blacklist. I became suspicious this time when the agent stated that they never had a blacklist. So, I wrote to its customer service. The only reply I got was to call. Once these this matter is cleared up, I will switch my email back to Cox and see what happens.

Thanks, EM for the follow-up.

John

Edit: Make that 19 notices. The obstruction for the Armstrong account seems to have been removed.
 
Last edited:
Status
Not open for further replies.
Cookies are required to use this site. You must accept them to continue using the site. Learn more…