Re: [exim] Reminder: ClamAV 0.95 minimum from 2010-04-15

Jeroen van Aart wrote:
> Martin A. Brooks 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 hope no one 'hates' anyone over it.

Basically, the long saga of the ever-developing RFC 'chain' for smtp (centered
on 822) requires bothway resolution - hostname to IP and IP to hostname.

It dosn't mention the 'how' of accomplishing that - PTR RR or a note from the
teacher or just making a wish. Not its job.

But it does also require use of, and compliance with the rules for ... DNS

It is in the RFC's on DNS that we find the 'how' - a PTR RR.

But not an absolute 'MUST' for their existence, nor a specific rule that smtp
MUST use a PTR RR. It is not the job of an RFC on DNS to redefine smtp or any
other service.

The RFC's on the top-level architecture are less forgiving, wherein ANY host
that is publically accessable 'MUST' have the requisite DNS credentials -
reverse resolution specifically among those, hence the in.arpa toolset and DB.

That RFC doesn't care about smtp or any other application protocol. Like most
RFC, it relies on other RFC specific to the details.

So - while the rule is not specific to or limited to smtp, 'Any public...' is a
big hammer. A very big hammer.

smtp just happens to be one of the Well Known Services that is more commonly run
as 'publically accessable' than not. It now gets harder to wiggle away - even if
we switch to port 24. VPN and/or non-routable LAN provide a way - until we need
to gateway.

IF an smtp host is 'publically accessable' it MUST obey the rule as to having a
PTR RR. Not because it is smtp. Because it is 'public'.

AND MUST use DNS.

This time because that part is BIOTh a general and an smtp requirement.

- Not all PTR RR need be usable to an MTA. The 'generic' ones commonly used by
dynamic adsl pools are not. Deliberately so, BTW, as no certainty is provided
that even a long-term DHCP lease holder will always have the same one.
But neither are they intended for operating MTA. Most ISP ToS so specify ww/r
their 'dynamic' IP pool. Many even voluntarily list them in RBL.

So what we have here is (at least) three 'Catch 22' or overlapping 'Venn'
diagrams - the common area of which says that if you want to run a 'publically
accessable' smtp host it must have - by inference - proper DNS credentials which
include a means of bothway resolution. There being few alternatives to a PTR RR
for that purpose, we make the further inference that there ain't no other
approved way but for said requirement to mean a PTR RR.

Lest we forget, that in turn implies a fixed IP as well.

Convoluted?

Perhaps more than it could be.

But eminently heirarchical - and so runneth the way of the 'net and its RFC's.
Each 'chunk' attempting to do a definable subset of the work, and do it well.

FWIW - none of this requires a recipient to reject those who ignore the rules.

In fact, in the case of FQDN resolution fail at HELO time - driven by similar
requirements as just covered - it is even suggested that we should NOT reject -
merely penalize with higher scoring as possibly not what it claims to be.

The missing PTR RR is tougher because it breaks the rst of the lookup chain and
says in effect:

'this server is NOT following the rules for a public facing box'

Ergo we are entitled to take it at its own word and refuse to allow it to
connect as an MTA on port 25. MUA on port 587 are a whole 'nuther matter.

Server admins may still choose to remain more forgiving than that. But it is not
because they are required to be.

So if Martin had said 'there is no RFC that *requires me to reject* for lack of
PTR RR' he would not be wrong. Just less discriminating than IANA/IETF expects.

Spammers love such generous folk. The rest of us seldom have that luxury.

'lie down with dogs...' and, fleas or no - you begin to smell like them.

Walk like a duck, talk like a duck...

... ID like a zombot...

Why would one NOT reject such an arrival?

Bill