On Fri, 2 Apr 2004, Ian A B Eiloart wrote:
> > There's a way to make exim do the callout check using an address
> > different from <>?
>
> No, if you call out with another address, then they call out to check that
> address, then you call out to check their address, then they..
>
> Where would it end.
Not far away from here, I think:
2004-04-02 14:54:31 H=sc009pub.verizon.net [206.46.170.188]
F=<antispam328315@???> rejected RCPT
[...snip...]
"j_workman_qm" isn't recognised as a valid email recipient here.
> > Or any solution aside removing the check from certain
> > domains? (some free internet/email providers here are using qmail and
> > blocking <>, so it'll be soon a spam nest)...
Which is why (with some exceptions) we let such senders block
themselves. exim does this for free, on any of the domains which we
included in our callout_domains file (I've discussed this in earlier
mails to the list), as in this sample:
2004-04-02 11:08:23 H=nt1.chvs.tyc.edu.tw [203.72.219.3] sender verify
fail for <yuanna@???>: response to "MAIL FROM:<>" from
mx.pchome.com.tw [211.20.188.150] was: 562 Access deny for
2004-04-02 11:08:23 H=nt1.chvs.tyc.edu.tw [203.72.219.3]
F=<yuanna@???> rejected RCPT <a.flavell@???>:
Sender verify failed
> Right now, I reckon, sender verification
> blocks more spam than denying bounce messages.
So the spammer response is (1) to fake envelope sender domains whose
MTA says OK to RCPT regardless of whether the addressee is valid or
not, and/or (2) faking real users rather than random invented
localparts. Both of which were obvious predictions of the
anti-callout brigade. But as long as callout works for keeping a
worthwhile proportion of spam out, I'm content to keep using it, at
least on the selective basis which we use.
