Re: [exim] callout verification

On Sun, 20 Feb 2005, Nigel Metheringham wrote:

> If they don't accept mail from <> then they are broken[*].

Indeed. When I'm investigating some item of spam which got past our
defences, if I find that the envelope-sender's MTA rejects mail
from:<> , then I'm only too happy to stick their domain into our
callouts list, irrespective of whether they were genuinely involved in
the spamming or not. They can then trip themselves over their own
stumbling block until they get that sorted out, in addition to any
spammers who are counterfeiting their addresses.[1]

Unfortunately, there's a small but non-zero number of such sources
from which our users genuinely /do/ want to get mail, and over whom
neither we nor our users have sufficient clout, on our own, to
persuade the offenders to resolve the misbehaviour.

Though I see that some of them, in the course of time, have repaired
the fault anyway, despite initially claiming that they were doing it
as (some kind of unexplained) defence against spam.

> If they think rejecting mail from <> is an appropriate spam control
> solution then they are more stupid than most on the internet - and
> that puts them way down below slime-mould, bacteria and marketeers.

"You might say that...."

But as long as others are willing to implement workarounds for this
misbehaviour, we get told (when the subject ever comes up) that we're
the only ones who are "having a problem", and so it can't possibly be
/their/ fault. You and I know just how faulty that logic is - but
it's hard to get the message over.

> > MAIL FROM: postmaster@local_domain.it

Or in actual practice, we get a transaction claiming to be from:

antispam123456@???

(well, I munged the number).

> Now think what happens if you are talking to a host that also does
> call- back verification.

These particular noodles accept any bogus address you offer them
in a callout. To quote from my manual script's report:
___
/
now attempting MAIL FROM:<> command...
attempting RCPT TO antispam123456 ...
attempting RCPT TO postmaster...
now attempting RCPT TO with bogus address...

*** Urgh, west.verizon.net accepted the bogus addressee
\___


Sigh. I suppose they must have some explanation which seems to make
sense to them. Admittedly there's no /mandate/ to reject bad
addresses at RCPT time, and it's understandable that some high-volume
mail services consider callouts to be as much of a pest as the spam
they're aiming to prevent (but the list has discussed that aspect
several times before...)


On the other hand, I notice that there are various newsletters and
suchlike bulk mails which look otherwise bona fide (i.e in the sense
that it's plausible that our users signed-up for them and actually
want to receive them), but which come with their envelope sender set
to <>. In my view it's also wrong to fake a productive mail as a
delivery status report, as it is to fake a DSN as a productive mail.
Any views on that?

best regards

[1] mail to postmaster/abuse addresses excepted, as usual