Re: [exim] automatically blacklisting clients that fail SMTP

Bill Hayles wrote:
> Hi, Ian
>
> I suspect we are not going to agree, and this thread has nothing to do with
> Exim, so I'm not going to bore everybody by going round in circles.
> All I defend is the right of a small mail server (that doesn't spam and
> obeys the rules) to run without the need to use any sort of smart host.
> However ...
>
> On Tue, 14 Jun 2011 09:31:55 +0000 in message number<57D6D8D6-CE17-4013-A0BA-B1CD62BE254D@???>, received here on 14/06/2011 13:09:33, Ian Eiloart<iane@???> said:
>
>
>>
>> SPF lets a domain owner say which IP addresses their email is expected to
>> originate from. It might be nice to also allow IP address owners to
>> specify which domains are expected to originate from their IP addresses.
>> For example, an ISP might permit a small company to use port 25, but
>> publish a set of DNS records that let the world know that the email
>> originating from those IP addresses is going to (mostly) use a particular
>> set of sender domains. I don't know whether that's easily achievable
>> technically, but it would be nice to be able to check with the IP address
>> owner as well as the domain owner.
>
> It's an interesting idea, and one I have no problem with in theory. In fact
> I think it would be much easier for me than it would for a hosting service
> that has new domains added daily, if not more frequently.
>
> I can see Telefonica looking on this as a way of extracting more money from
> their fixed IP account customers.
>
> The problem comes in that 95% (maybe more) of mail originating from
> 80.35.22.107 will have a sender@???. However, some of my account
> holders have more than one e-mail address and may wish to send via my server
> using that address. Perfectly OK, as everybody (even me!) has to
> authenticate via ESMTP to send to anywhere other than local domains. Your
> proposal would make that difficult, if not impossible.
>

I don't see how.

Ian's proposal is actually available from 'some' SME-providers, as is.

Further, given that DHCP leases can last for 3 to 6 months 'often' and
over a year 'sometimes', it could be relatively painless for any ISP who
chooses to do so, to offer auto-updating PTR RR (real, not generic) and
sync'ed A and MX records, optionally SPF/DKIM 'assistance', not only on
their fixed leases, but on selected dynamic ones.

So an entity choosing to run a full-house MTA on residential/SOHO
DHCP/NAT'ed broadband would not necessarily even need dyn-whatever DNS
services OR a more public-facing smarthost.

IPv6 (eventual, sometime, maybe) takeup will probably be the shift in
that direction.

So what am I looking for with an rDNS check?

Basically that the connecting IP has the credentials of a traceable and
reversible source. Which one is still 'don't care.

At acl_smtp_connect, the envelope-from and From: headers are not yet
available anyway. Nor do I care, even later. I'm at all concerned with
vetting that part of MUA settings.

Likewise, for me at least, SPF, DKIM and sputniks add no value, nor
would a sender_verify callout.

- The good guys are already 'good enough' from an rDNS check

- the commercial marketing firms that are NOT 'hiding' have taken even
more pains than average to get all the DNS basics PLUS those extra
parasites to vet properly...

... but are still going to be SA-hammered and/or LBL'ed for sending
unwelcome *content*. And I include, for example, American Express,
despite 41+ years with them.

Callouts, SPF, DKIM, turn into 'diminishing returns' Real Soon Now once
the 'bots have been subdued with an eminently cacheable (in DNS
food-chain if not Exim) rDNS check.

KISS - and spending a small amount of effort keeping LBL and LWL tuned,
works with far less per-every-message overhead, and let us drop
SpamAssassin and sputniks some time ago.

Once one is down to fewer than two spam in five days per user, the risk
of falsing has already become greater than any remaining gains.

YMMV, of course - but I just wish my dead-tree mail was as easy and
cheap to keep clean.

Bill

韓家標