Host mailman.ampr.org (where this and other mailing lists are hosted) has moved from address 199.249.230.93 to 44.76.7.7. This change was made because the 199.249.230.93 address was being blocked by too many blacklists due to other activity on the subnet.
Unfortunately, whenever a mail handler such as 'mailman' gets a new address, it loses all the good will and reputation it has previously earned in various spam filters, so some recipients may miss out on a few messages because of over-enthusiastic spam filtering.
There is nothing I know of to enhance its reputation except time. Your patience is appreciated. - Brian
Funny, I found this message in my spam folder... :-)
________________________________________ De : 44Net 44net-bounces+petem001=hotmail.com@mailman.ampr.org de la part de Brian Kantor via 44Net 44net@mailman.ampr.org Envoyé : 27 juillet 2019 20:31 À : 44net@mailman.ampr.org Cc : Brian Kantor Objet : [44net] mailman.ampr.org new IP address
Host mailman.ampr.org (where this and other mailing lists are hosted) has moved from address 199.249.230.93 to 44.76.7.7. This change was made because the 199.249.230.93 address was being blocked by too many blacklists due to other activity on the subnet.
Unfortunately, whenever a mail handler such as 'mailman' gets a new address, it loses all the good will and reputation it has previously earned in various spam filters, so some recipients may miss out on a few messages because of over-enthusiastic spam filtering.
There is nothing I know of to enhance its reputation except time. Your patience is appreciated. - Brian
_________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
On 28.07.2019 02:31, Brian Kantor via 44Net wrote:
Unfortunately, whenever a mail handler such as 'mailman' gets a new address, it loses all the good will and reputation it has previously earned in various spam filters, so some recipients may miss out on a few messages because of over-enthusiastic spam filtering.
It ended up marked as spam on my server
Cause: The host name specified in HELO does not match IP address.
You you should fix that.
As I said, time will fix that - it's a question of when the old address expires out of DNS caches and the new one is learned.
That's likely ok by now, since the DNS TTL was an hour. But until the email reputation of the new address builds, it's still quite possible that messages will be marked as spam by some overzealous anti-spam algorithms. - Brian
On Sun, Jul 28, 2019 at 08:40:28AM +0200, Pedja YT9TP via 44Net wrote:
It ended up marked as spam on my server Cause: The host name specified in HELO does not match IP address. You you should fix that.
On 28.07.2019 09:42, Brian Kantor wrote:
As I said, time will fix that - it's a question of when the old address expires out of DNS caches and the new one is learned.
DNS should be updated by now. Have you set reverse DNS accordingly?
That's likely ok by now, since the DNS TTL was an hour. But until the email reputation of the new address builds, it's still quite possible that messages will be marked as spam by some overzealous anti-spam algorithms.
This is not the case. I run this mail server. It simply checks if HELO information is valid.
Interesting. When I look up the IP address, the rDNS returns the correct answer:
% host 44.76.7.7 7.7.76.44.in-addr.arpa domain name pointer mailman.ampr.org.
What happens when you look it up on your host? - Brian
On Sun, Jul 28, 2019 at 10:06:18AM +0200, Pedja YT9TP wrote:
On 28.07.2019 09:42, Brian Kantor wrote:
As I said, time will fix that - it's a question of when the old address expires out of DNS caches and the new one is learned.
DNS should be updated by now. Have you set reverse DNS accordingly?
That's likely ok by now, since the DNS TTL was an hour. But until the email reputation of the new address builds, it's still quite possible that messages will be marked as spam by some overzealous anti-spam algorithms.
This is not the case. I run this mail server. It simply checks if HELO information is valid.
-- 73, Pedja YT9TP
Checkout: https://pedja.supurovic.net/ https://yu1abh.uzice.net/ https://www.facebook.com/yu1abh/ https://www.facebook.com/groups/yu1abh.konstruktori/ http://www.radio-amater.rs/
On 28.07.2019 10:42, Brian Kantor wrote:
Interesting. When I look up the IP address, the rDNS returns the correct answer:
% host 44.76.7.7 7.7.76.44.in-addr.arpa domain name pointer mailman.ampr.org.
What happens when you look it up on your host?
Resolves to mailman.ampr.org too.
I will check mail server logs to see if I can find anything interesting.
Greetings,
On Sun, 28 Jul 2019, Brian Kantor via 44Net wrote:
As I said, time will fix that - it's a question of when the old address expires out of DNS caches and the new one is learned.
It *should* be a multi-step process:
1) The Hostmaster sets the TTL cache time setting for the impacted Resource Record in DNS to less than one hour.
2) The Sysadmin waits until the TTL cache time has gone by. So if it was set to 3 days, s/he *WAITS* 3 days *before* performing the IP address cutover. This ASSURES that no one will cache the old IP addres for more than 1 hour.
3) The SysAdmin executes the IP re-addressing of the desired server. The Hostmaster also updates the new IP address into the DNS resource record, but *LEAVES* the TTL cache time set to a SHORT period of time (1 hour) until users report NO problems with the server at the new address. In this way *IF* you have to back out the change, and switch back to the original address, no one will be caching the NEW address for more than an hour. Keep the impact low....
4) Once it is verified that NO ONE is having problems with the new IP address and the sevice is fully functional at its new address, the Hostmaster will up the TTL cache time back to the original setting (3 days, or whatever).
*NEVER* just switch the IP address of an important server and then *blame* DNS Cache for unreachability problems, when in reality it was just poor execution :(
Sure, email from MAILMAN.AMPR.ORG is *not* life saving nor is it going to affect anyone's lives, but practicing good Sysadmin skills is "A Good Thing"(tm) :)
Thanks for the work you do,
--- Jay WB8TKL
I completely agree with Jay (WB8TKL) that is the correct way to change a DNS of a service.
" But why not reconfigure the old server to forward incoming mail to the new one instead?" Source: Https://serverfault.com/questions/595274/move-mail-server-to-a-new-server-with-no-downtime
- Bradley (KG5GPK)
On Mon, Jul 29, 2019, 11:11 AM Jay Nugent via 44Net 44net@mailman.ampr.org wrote:
Greetings,
On Sun, 28 Jul 2019, Brian Kantor via 44Net wrote:
As I said, time will fix that - it's a question of when the old address expires out of DNS caches and the new one is learned.
It *should* be a multi-step process: 1) The Hostmaster sets the TTL cache time setting for the impacted Resource Record in DNS to less than one hour. 2) The Sysadmin waits until the TTL cache time has gone by. So if it was set to 3 days, s/he *WAITS* 3 days *before* performing the IP address cutover. This ASSURES that no one will cache the old IP addres for more than 1 hour. 3) The SysAdmin executes the IP re-addressing of the desired server. The Hostmaster also updates the new IP address into the DNS resource record, but *LEAVES* the TTL cache time set to a SHORT period of time (1 hour) until users report NO problems with the server at the new address. In this way *IF* you have to back out the change, and switch back to the original address, no one will be caching the NEW address for more than an hour. Keep the impact low.... 4) Once it is verified that NO ONE is having problems with the new IP address and the sevice is fully functional at its new address, the Hostmaster will up the TTL cache time back to the original setting (3 days, or whatever). *NEVER* just switch the IP address of an important server and then*blame* DNS Cache for unreachability problems, when in reality it was just poor execution :(
Sure, email from MAILMAN.AMPR.ORG is *not* life saving nor is itgoing to affect anyone's lives, but practicing good Sysadmin skills is "A Good Thing"(tm) :)
Thanks for the work you do, --- Jay WB8TKL
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Also one more follow up, if I would recommend flushing the Google cache which is well connected : https://developers.google.com/speed/public-dns/cache
On Mon, Jul 29, 2019, 7:14 PM Bradley Parker yofun111@gmail.com wrote:
I completely agree with Jay (WB8TKL) that is the correct way to change a DNS of a service.
" But why not reconfigure the old server to forward incoming mail to the new one instead?" Source: Https://serverfault.com/questions/595274/move-mail-server-to-a-new-server-with-no-downtime
- Bradley (KG5GPK)
On Mon, Jul 29, 2019, 11:11 AM Jay Nugent via 44Net < 44net@mailman.ampr.org> wrote:
Greetings,
On Sun, 28 Jul 2019, Brian Kantor via 44Net wrote:
As I said, time will fix that - it's a question of when the old address expires out of DNS caches and the new one is learned.
It *should* be a multi-step process: 1) The Hostmaster sets the TTL cache time setting for the impacted Resource Record in DNS to less than one hour. 2) The Sysadmin waits until the TTL cache time has gone by. So if it was set to 3 days, s/he *WAITS* 3 days *before* performing the IP address cutover. This ASSURES that no one will cache the old IP addres for more than 1 hour. 3) The SysAdmin executes the IP re-addressing of the desired server. The Hostmaster also updates the new IP address into the DNSresource record, but *LEAVES* the TTL cache time set to a SHORT period of time (1 hour) until users report NO problems with the server at the new address. In this way *IF* you have to back out the change, and switch back to the original address, no one will be caching the NEW address for more than an hour. Keep the impact low....
4) Once it is verified that NO ONE is having problems with the new IP address and the sevice is fully functional at its new address, the Hostmaster will up the TTL cache time back to the original setting (3 days, or whatever). *NEVER* just switch the IP address of an important server and then*blame* DNS Cache for unreachability problems, when in reality it was just poor execution :(
Sure, email from MAILMAN.AMPR.ORG is *not* life saving nor is itgoing to affect anyone's lives, but practicing good Sysadmin skills is "A Good Thing"(tm) :)
Thanks for the work you do, --- Jay WB8TKL
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
-
Bradley Parker -
Brian Kantor -
Jay Nugent -
Pedja YT9TP -
pete M