From:
Um.. Don.. so you're saying that because you've implemented a policy that rejects email based on the contents of the PTR, that this is Telecom's fault and they need to 'fix' it? Which 'we' are you referring to and what 'discussion' was there? Since when does NZNOG get to create an operational consensus of that nature and then blindly assume that everyone will implement it? Broadcasting the issue on NZNOG would seem to be inappropriate; this isn't a fault, this is collateral damage of a policy decision you've chosen to make. I doubt that nzvanlines.co.nz would be the only sender affected, but the impact would seem to be on your customer. You've made the decision to do this; live with the consequences or change your approach. The IP of the nzvanlines.co.nz MX record has a valid matching forward/reverse pair - which is the basic reputational check many MTA's perform - the fact it contains suggestions that it might be from a residential-grade connection is not something _I_ would choose to use when attempting to filter spam; (been there; onceuponatime SORBS attempted to run a blacklist that identified dynamic IP address ranges. Persistent false positives meant that this was eventually a lost cause.) There are plenty of ways to reduce your spam-count, this wouldn't seem to be a smart one; In this case NZ Van Lines would need to decide if making wholesale changes to the way they deliver email to the world is worthwhile based on their inability exchange mail with your platform, and your customer needs to decide if the disruption to their email service is worth the cost of the measure that's been put in place. And you need to decide whether it's worth the time and energy and potential loss of customers, should they decide to move to a service provider who can effectively filter spam without blocking legitimate email for what seems to be a fairly inappropriate reason. Mark. On 10/09/13 22:17, Don Gould wrote:
From:
mailto:gillian.halkett(a)nzvanlines.co.nz> SIZE=50696 Tue 2013-09-10 15:27:37: [126020:1] <-- 250 2.1.0 Ok Tue 2013-09-10 15:27:37: [126020:1] --> RCPT To: mailto:jenna(a)christchurchapartments.co.nz> Tue 2013-09-10 15:27:38: [126020:1] <-- 553 5.7.1 <222-154-247-46.adsl.xtra.co.nz http://adsl.xtra.co.nz[222.154.247.46]>: Client host rejected: AUTO_[A|X]DSL We aren't accept direct connection not from dedicated SMTP servers. Please use your internet provider SMTP Server. Tue 2013-09-10 15:27:38: [126020:1] --> QUIT We're rejecting mail from nzvanlines.co.nz because they're running their smtp server on a service with a|x|vdsl in the ptr record.
I think we've had this discussion on list before, and iirc we decided that we just get providers to update ptr records, but I'm a bit scared to ring L1HD and ask for a ptr change.
Is there an admin on list from Telecom who can work with your customer to fix this for as I doubt it's only us it's impacting?
D -- Don Gould 31 Acheson Ave Mairehau Christchurch, New Zealand Ph: + 64 3 348 7235 Mobile: + 64 21 114 0699 Ph: +61 3 9111 1821 (Melb)
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
On 2013-09-10, at 17:25, Mark Foster
Um.. Don.. so you're saying that because you've implemented a policy that rejects email based on the contents of the PTR, that this is Telecom's fault and they need to 'fix' it?
It's not an uncommon policy. People even tried to document it in the IETF, although they didn't get very far (I think the idea is too ugly to imagine hanging it on the otherwise pristine walls of the ivory tower). Drawing Xtra's attention to it does not seem like a bad thing. Using NZNOG as the primary way to contact Xtra mail admins seems a bit unfortunate, especially if it's necessary :-) Joe
On 11/09/13 09:31, Joe Abley wrote:
On 2013-09-10, at 17:25, Mark Foster
wrote: Um.. Don.. so you're saying that because you've implemented a policy that rejects email based on the contents of the PTR, that this is Telecom's fault and they need to 'fix' it? It's not an uncommon policy. People even tried to document it in the IETF, although they didn't get very far (I think the idea is too ugly to imagine hanging it on the otherwise pristine walls of the ivory tower).
Drawing Xtra's attention to it does not seem like a bad thing. Using NZNOG as the primary way to contact Xtra mail admins seems a bit unfortunate, especially if it's necessary :-)
Hi Joe, and others - I've come across it before, and if IETF had moved on it and saw widespread adoption as a result, perhaps it'd work. However without ratification, any measure like this is a cost:benefit analysis and requires the person implementing the policy to decide if the cost is worth it, including as necessary, negotiating with remote mail admins and attempting to convince them that their arrangements aren't 'correct enough'. Or creating the means to whitelist particular senders. The people who run the nzvanlines.co.nz mail platform are the only people who need to care on this; they can request a DNS change from Telecom/Xtra or they can switch to Xtra's 'smarthost'. Or Don can choose not to use this particular policy, or they can whitelist this particular domain or IP address. I don't see Telecom setting up custom PTR's by default; they've created a matching forward/reverse pair and anything other than that would seem to be their customers concern. This is not a 'fault' and nor does it need to be 'fixed'; it's a combination of decisions made by the two mail server admins and if they create a conflict, it's up to them to sort it out. A broadcast on NZNOG asking for the ISP of one party to step in and make arbitrary changes to meet the requirements of one side of the conflict, would seem inappropriate.
From where I sit, it's not Telecom's problem until Telecom's own customer approach them about it.
Mark.
On Tue, Sep 10, 2013 at 05:31:36PM -0400, Joe Abley wrote:
On 2013-09-10, at 17:25, Mark Foster
wrote: Um.. Don.. so you're saying that because you've implemented a policy that rejects email based on the contents of the PTR, that this is Telecom's fault and they need to 'fix' it?
It's not an uncommon policy. People even tried to document it in the IETF, although they didn't get very far (I think the idea is too ugly to imagine hanging it on the otherwise pristine walls of the ivory tower).
Drawing Xtra's attention to it does not seem like a bad thing. Using NZNOG as the primary way to contact Xtra mail admins seems a bit unfortunate, especially if it's necessary :-)
thing is that ptr just says ADSL - it doesn't say that it's dynamic. And looking at Spamhaus it's not listed in SBL, or PBL. Spamhaus PBL records pretty accurately on policies for IP blocks. If anyone on ADSL is a lesser user, it's akin to the APNIC blocking that some people have been known to do because "lots of spam comes from China", even though the majority of spam comes from the US. I understand wanting to block IP's from ADSL users who haven't opted out of policy blocking, but I'm not even sure that blocking of lack of reverse DNS is a positive thing - Recently there's been quite a few IPv6 configurations without working IPv6 reverse DNS which can lead to losing some mail. Personally I've noticed the bulk of spam coming through from hotmail, yahoo, and other free email providers with all the right boxes ticked, but completely malicious users. That said I block using Spamhaus which blocks the majority of the low hanging fruit, without giving excessive false positives. Ben.
My thanks to the person who pinged me a number to call for Telecom to connect with someone who knew what a PTR record is. I called them this morning and they're going to make contact with their customer to offer assistance. D On 10/09/2013 10:17 p.m., Don Gould wrote:
participants (5)
-
Alastair Johnson
-
Ben Aitchison
-
Don Gould
-
Joe Abley
-
Mark Foster