<br><br><div class="gmail_quote">On Mon, May 20, 2013 at 4:25 PM, Mark Delany <span dir="ltr"><<a href="mailto:g2x@juliet.emu.st" target="_blank">g2x@juliet.emu.st</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 20May13, Peter Tiggerdine allegedly wrote:<br>
<br>
> So we should all just ignore RFC's because our largest trading partner<br>
> decide they don't to play by the same rules as the rest of the world.. WTF?.<br>
<br>
</div>For some reason you think that all RFCs are perfect and are always<br>
pragmatically based. Where did you get that idea from?<br>
<br></blockquote><div><br></div><div>"Rules are rules Jacko" RFC's allow us to all have a common understanding of what to expect. If your software and implementation can't pass RFC compliance then you should find a better vendor and implementation engineer.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Geeks have been banging the "must have a reverse" drum for, what, 20<br>
years now? The evidence is in, it's a lost cause because time-pressed<br>
admins rarely waste their time on useless fluff that is a maintenance<br>
headache.<br>
<div class="im"><br></div></blockquote><div><br></div><div>I'd like to see how you come up with that "evidence" sounds more hearsay and circumstantial than anything else. Real network admin and email admin know PTR is mandatory.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> How exactly is it more difficult than forward records?<br>
<br>
</div>Well, for a start arranging the delegation of reverse can be a lot<br>
more difficult. If your ISP doesn't do a good job, </blockquote><div><br>Find a new ISP. Simple resolution. Real ISP with business customers know the story an have systems in place.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
or doesn't want to<br>
delegate you have zero recourse. Managing your forwards is completely<br>
under your control and does not require co-operation from any upstream<br>
delegation.<br></blockquote><div><br></div><div>Disgree entirely. Managing forward requires the co-operation of the DNS hosting provider, not mention your ISP to correctly route traffic.</div><div> </div><div>Sounds more like "WAA" I tried to run a mail server off a residental link because I didn't want to pay for system and SLA WAA"</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
For seconds, nothing stops working if the reverses are missing or<br>
wrong. </blockquote><div><br></div><div>Email and DNS (every tried to remove PTR for a name server?)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Third, if they get out-of-date nothing knows or cares. </blockquote><div><br></div><div>span filters care as do your customers when there email starts to get blocked.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Forth,<br>
if you make completely bogus entries in your reverses, you make the<br>
RFC Police happy, but what is that really achieving apart from<br>
demonstrating basic scripting skills?<br></blockquote><div><br></div><div>It demonstrates that the IP owner knows your running a mail server as they've put records in or you've setup sufficient infrastructure to handle PTR as the owner of the IP space.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
In any event, it's not a question of difficulty, it's a question of<br>
cost/benefit. And as we see all the time, a lot of places don't<br>
believe that one exists.<br></blockquote><div><br></div><div>Cost of you don't do it, YMMV on email reachability.</div><div><br></div><div>Cost if you do, everything works include SPF records.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
When you block on a missing reverse, you're mostly using that as a<br>
proxy to recognize an overworked or under-trained admin or a<br>
recalcitrant upstream provider. None of these have much bearing on<br>
what is being run on that IP.<br></blockquote><div><br></div><div>Refer to find another ISP or hire more admins. Not a technical problem.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
So I guess if your goal is to punish an overworked admin, continue to<br>
block away.<br>
<br></blockquote><div>My goal is to reduce spam and protect my users and the infrastructure. OH&S issue there also. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The other problem is that spammers are well aware that a lack of<br>
reverse is used by some naive filters, so guess what? They retry the<br>
same payload to you from another IP if the first IP fails. They will<br>
keep going until one of their IPs is accepted by you.<br>
<br>
You may smugly think you've blocked them, and they smugly know that<br>
they got to you via another route.<br></blockquote><div><br></div><div>doubt it. It's call perimeter audits. Do it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
For those who believe that blocking an a lack of reverse truly stops<br>
spam, how do you know it didn't show up some time later on an IP that<br>
happens to have a reverse?<br></blockquote><div><br></div><div>Strawman arguement - ignoring.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
<br>
Mark.<br>
_______________________________________________<br>
AusNOG mailing list<br>
<a href="mailto:AusNOG@lists.ausnog.net">AusNOG@lists.ausnog.net</a><br>
<a href="http://lists.ausnog.net/mailman/listinfo/ausnog" target="_blank">http://lists.ausnog.net/mailman/listinfo/ausnog</a><br>
</div></div></blockquote></div><br>