Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
From: Frank Cusack (fcusackfcusack.com)
Date: Tue Jan 19 2010 - 14:12:58 CST
On January 17, 2010 3:16:54 PM -0600 Stan Hoeppner <stanhardwarefreak.com>
> Have you been in prison or incapacitated for the last few years Frank?
> You seem to be out of touch with many established standards/norms.
Indeed I have. One of those. :)
Also I question "established" norms because times change and often they
don't make sense "now". For example default TCP timers are horribly
outdated for today's networks.
> First you argue for multiple PTR records for mail sending hosts. Then
> you argue that no PTR should be required for mail sending hosts. You've
> just proposed both extremes of the debate, yet the debate on this was
> over long ago, and everyone else is right in the middle: one PTR
> required for a mail sending host.
I did not argue for multiple PTR records for mail or any other host.
Please re-read all my messages on the subject if you care to take the
time. I merely argued for *postfix support* for multiple PTR records.
In fact I think multiple PTR records (even for the one case I found
which does require it -- zeroconf) are idiotic and *if* I were to argue
either way it would be against it. But at the same time, I don't
believe postfix should reject clients with multiple PTR records (and
now I know it doesn't).
And even now, I haven't argued for no PTR records either. I've merely
asked what is the reason to require a PTR record. I disagreed with
the first reply that it's a valid anti-spam filter, however I didn't
put forth any opinion on whether or not I think (a single) PTR record
is useful for some other reason. I was trying to find out what people's
thoughts are on it. I can see where you might imply what my opinion of
them is however but let me assure you I have not made up my mind yet.
Please stick to responding to the actual question posed. :)
I'll read the rest of the thread before replying further.