Mike Cardwell wrote:
> On 13/04/2010 21:01, Jeroen van Aart wrote:
>
>>>> Deal with the IANA/IETF on your disagreement with what they - or the major
>>>> carriers who DO read and comply [1] - require, not with me.
>>> Please provide a link to the RFC you are talking about.
>> It's quite pointless whether an RFC exists or not, what happens
>> inpractice kind of dictates what you can do and can't.
>>
>> Try to send out email without an rDNS it will become more problematic
>> over time and the more destinations you send email to.
>>
>> More and more spamfilters block on the lack of an rDNS and a large % of
>> those will also block if the rDNS is generic and/or comes from an IP
>> range that's supposed to not send emails, say dynamic ranges assigned by
>> ISPs to home internet accounts. Many of those ISPs voluntarily list
>> those ranges in blocklists such as spamhaus as ranges which are not
>> supposed to send email.
>>
>> So it's kind of an uphill struggle and everyone will end up hating you ;-)
>
> I think you might have missed Martin's previous email. Let me quote it
> below for you:
>
>> I think we've had this debate before, but there is no RFC that
>> mandates that reverse DNS exists.
>> It's your opinion that it should do so, and I don't especially
>> disagree with you, but please stop stating that it's an RFC
>> requirement. It simply isn't and you mislead people when you say so.
>
> Martin merely disputed that it is an RFC requirement.
On which he was (still) wrong.
> He didn't say that
> he thinks it's ok to not use RDNS. In fact, he implied the opposite. He
> thought misleading information was posted to the list and wanted it to
> be corrected.
But posted misleading information to alter correct information.
A habit you jave shared with him in the past as well as just now.
C'mon guys - if an old man blind in one eye and impaired in the other can read
the RFC's how about a bit of simple looking at 'em on your part.
In RFC 822 et seq, how do you interpet the 'MUST' with regard to;
"6. SUPPORT SERVICES
6.1 DOMAIN NAME TRANSLATION
6.1.1 INTRODUCTION
Every host MUST implement a resolver for the Domain Name System
(DNS), and it MUST implement a mechanism using this DNS
resolver to convert host names to IP addresses and vice-versa
[DNS:1, DNS:2].
"
also summarized in tabular form in 6.1.5
How can it accomplish that both way lookup requirement if there are no records
with which to do so?
Well if we 'MUST implement a resolver for the Domain Name System' it pays to go
and see what the rules for that include in the RFC on DNS.
That will then lead you to the 'top level' or root-servers and what THEY require
as to reverse working for in.addr.arpa.
Then back down the chain to how that had to be given finer granularity for sub
delegation...
.. use of real names .. yadda, yadda... and so on.
Not to forget roughly four to six updates and revisions to any of the original
RFC's - some still in work.
I didn't pull this stiff out of my a** - but for sure there is enough of it to
wipe with for months.
>
> The obvious and reasonable response by Bill to Martin would have been to
> quote the alleged RFC,
For what? The 'nth' time? grep the archives.
He - and you do not want to read them and will not stop denying they exist.
Is that 'lazy' or 'spammer friendly'?
You guys running a botnet or something?
> thus proving his point. Instead of providing the
> alleged evidence, Bill merely repeated the claim in his
> characteristically verbose manner, and without providing the evidence.
> Take from that what you will.
>
There is a ton of paper with sometimes a mere sentance or two per document by
the time you find all of it that applies.
But the single one that IS in the smtp RFC (quoted above) might make one wonder
just HOW TF one is to comply with the MUST in bothway lookup w/o the presence
and use of PTR RR's in a DNS that can be 'seen'. Meaning that of the last-mile
authoritative IP-block holder of record, not just your local box.
By all means share your alternative means to meet that 'MUST' requirement with
us.... and the RFC which blesses them.
Bill
