28 Jul
2019
28 Jul
'19
1:31 a.m.
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
28 Jul
28 Jul
3:48 a.m.
Funny, I found this message in my spam folder... :-)
________________________________________
De : 44Net <44net-bounces+petem001=hotmail.com(a)mailman.ampr.org> de la part de Brian
Kantor via 44Net <44net(a)mailman.ampr.org>
Envoyé : 27 juillet 2019 20:31
À : 44net(a)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(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
7:40 a.m.
New subject: [SPAM] mailman.ampr.org new IP address
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.
--
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/
8:42 a.m.
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.
9:06 a.m.
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/
9:42 a.m.
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/
11:33 a.m.
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.
--
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/
11:24 a.m.
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
30 Jul
30 Jul
3:14 a.m.
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-w…
- Bradley (KG5GPK)
On Mon, Jul 29, 2019, 11:11 AM Jay Nugent via 44Net <44net(a)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 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
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
3:23 a.m.
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(a)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-w…
- Bradley (KG5GPK)
On Mon, Jul 29, 2019, 11:11 AM Jay Nugent via 44Net <
44net(a)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 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
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
1743
days inactive
1745
days old
9 comments
5 participants
participants (5)
-
Bradley Parker -
Brian Kantor -
Jay Nugent -
Pedja YT9TP -
pete M