Re: [exim] Rejecting messages with no "To:" or "Cc:" field i…

Chris Wilson wrote:
> Hi Paul,
>
> On Thu, 18 Nov 2010, Always Learning wrote:
>
>> Bill Hacker wrote .........
>>
>>> "Real folks" MTA have DNS creds. Botnet WinZombies do not. QED.
>>
>> The facts of everyday email receiving is some very large organisations
>> give out false HELO / EHLO and/or have non-resolving hosts.
>
> I don't think that's what Bill meant.
>
> Any kiddie can write a spam mailer that does a reverse lookup on its IP
> address to send a *valid* and *accurate* DNS HELO.

I agree. But that's also why I quit putting much weight on HELO mismatch. It has
to resolve. It doesn't have to have anything to do with an smtp server.

And if it is an abuser - say a DoS attack - those who own the netblock can track
the IP and time of day to a subscriber by IP with only marginally more work - if
any at all -than they could from their assigned 'generic' PTR RR.

>
> "Credentials" for me is "reputation": known good emails and very few spams
> originating from this server's IP address. I only care about its hostname
> if I have to guess whether it's dynamic or belongs to someone too big to
> block, like Google or Yahoo. I wish that I didn't have to make that guess.
>

You don't have to guess. Essentially ALL the majors have 'seen the light' - for
some years now - and DO have proper DNS entries, PTR RR especially. MSN/Hotmail,
Yahoo, GMail, AOL, etc. Even formerly lazy wanadoo and such have cleaned up
their act.

>> (1) HELO / EHLO must resolve to the IP address of the sending server;
>
> Which makes this test pretty useless. It's also difficult for hosts that
> send mail to destinations both inside and outside of NAT, without running
> split horizon DNS, which is also evil, and two wrongs does not make a
> right, and internal hostname + split horizon DNS != zero problems.
>

See above w/r HELO.

But PTR RR is another story. IF/AS/WHEN one *cannot* be assigned an 'smtp
useful' PTR RR, then one should expect to relay via a smarthost which DOES have
such.

For Joe Laptop, that's as simple as submitting via port 587 to wherever his
'home' server sits. For a SOHO, it may mean arranging to use the smarthost of
the connectivity provider. In extremis a traveler might have to fall back to
webmail - very wort-case have a supplementary account with another provider.
Note how often ' @gmail' addresses show up here on the list..

>> (2) The sending server (MTA) must have a resolving host name.
>
> This one is out of the control of the botnet owner, but most ISPs have it.
>
> For this to reduce spam significantly, ISPs would also have to remove
> reverse DNS from their zombie range. I'd rather that the ISP registered
> their dynamic IP space with the Spamhaus PBL instead.
>
Nice if the ISP do so. Nicer yet if the ISP also either block outbound 'to any
port 25' ELSE divert it to their own servers and require AUTH.

Any MANY now do just that.

Most ISP run their own MTA/smarthost off an IP NOT in the same portable range
they assign to connectivity customers in any case.

And MOST also have Tos that specifically prohibit operating an MTA from their
residential/SOHO/SME dynamic IP pools.

Yes - a fixed-IP and DNS entries usually require the 'small business' package.
But they have higher costs of admin and provisioning, so that's going to be the
case.

So I can - and do - LBL the dynamic-IP pools of Verizon, Comcast and the like -
without risk of missing *legitimate* traffic, even from their user comunity.

>> Exim provides excellent tools for rejecting spam but when large
>> organisations, some operating internationally, can not care less the
>> dilemma for others is whether to adhere to one's own standards or
>> succumb to accepting spam, virus and Trojans into the system.
>
> I wish that ISPs would block port 25 outbound except for registered
> outbound SMTP servers,

It's growing. Not because I/We propose it HERE.

But because it slams the door on botnets eating up their own bandwidth and
technical, admin and legal staff time. Read 'money'. Basic economics, not RFC's.

> ..and force all outbound mail through a spam filter.

With the door shut on bots, yes, filtering is nice on their smarthosts. But
malware and phish blocking far more important than dodgy advertising.

> I wish that spam filtering services didn't send out spam from their
> customers.
>

'nuther day, diff'rent discusson.

But far too many of 'em 'play with' spam - fondle it, smell it, taste it,
measure it for a prison uniform, cloth it - then pass it on in chains with a
*score*.

Too few simply reject at smtp-time. No glorious stats that way. Less 'evidence'
of how clever and 'valuable' they are.

>> I reject virtually everything not 100% correct. It produces a (so far)
>> 100% spam free operation. A selection of other people's standards can
>> be seen on sys.u226.com/t21/t21.php
>
> It's very easy to be 100% spam free: block port 25 inbound. You don't
> mention your false positive rate.
>
> Cheers, Chris.

'False positive rate' is pure cop-out.

The filters I use did not spring into being from the head of Zeus. And they
don't implement every subtle nuance of SHOULD or even MUST RFC's, either.

They were built over many years of learning and monitoring logs with 'warn' verb
experiments. And the experience - including mistakes - of all those HERE as well
as my own. Far too MANY of my own.

That included tailing and grepping horribly verbose logs and taking the time to
track down every single case of '..can't get email from..' reported by a
critical user community.

Most of the time we were able to provide a 'what needs fixed' detailed report
that could - but not always did - inspire and help their provider to fix a
general-case problem that was affecting ALL their outbound. Other times we had
to enter exemptions. Or craft special rules.

But if MY servers reject incoming, there is long-since not much 'false' about
it. MOST of the majors will also reject that traffic, and for the same RFC-based
reasons. MANY are more strict. I don't worry about HELO match, SPF, DK, DKIM, or
verify-sender at all, and have stripped SA of Bayesian plus a great many of its
other marginally useless or best-done-by-Exim tests.

So ...many of the complainants had OTHER places they could not reach.
So too with the rest of the comunity.

Some folks with that sort of incompetent or lazy provider switched to Gmail and
the like. What else could they do?

Exim's rDNS check is the 'gold standard' that wipes off a long-running average
of 89% of arriving garbage *here*. YMMV - but not by much.

LBL and RBL get most of the rest.

One server hasn't yet run SA at all in its entire ... 578+ days . . of uptime.
Yet on-passes near-zero spam. Exim + ClamAV + RBL & LBL are that good...

And I no longer spend hours perusing logs or reviewing and deleting spam....

Lest we forget ...

This thread WAS about blocking on 'perceived unwanted' header pattern/absence.

That's hard to do and not get wrong.

Advice to the OP?

Have a look at their *source*.
Many of these are malicious. Are yours even 'legit'?
If so, will the *sender* take advice?

If not, could they be more reliably blocked by rDNS, RBL, or LBL checks?

Or given an agonizing 'defer'?

Or a longish 'delay'?

Those who *care* might clean up their outbound-act.

Perpetually indifferent can be dropped on the floor of the data centre by LBL
more cheaply than by complex header parsing.

Get the 'basics' right, and you, and those you serve - get your *lives* back....

Bill