Re: [exim] Sender verify at extreme

Jethro R Binks napisał(a):

> I am somewhat near the fence on this issue, so I err on the side of
> caution and do not do callouts to arbitrary domains. I can see both
> points of view: I can see the value of callouts and the benefits to the
> would-be recipient, but I also see the damage that can be done to the
> sender domain whose address is forged.
> Nevertheless:
>
You take respectful stance, which in turn I respect. :-)


>> The main reason we use sender verify with callouts is that it eliminates
>> a huge amount of spam, and what can be more abusive than spam (incl.
>> e-mail phishing and frauds)?
>>
>
> But the cost is borne by those sender domains, requiring resources to deal
> with your callout.
>

Sure! Let's estimate those resources:

- you bear the cost of say, 0.00001 cent to prevent spammer from forging
this mail to bear your address/your domain on envelope; the costs in
particular consist of one TCP/IP session to your MX and four packets
sent each way (hello, mail from: <>, rcpt to:, quit, and responses of
your MX to each of those) per mail somewhere on the internet bearing
your address on the envelope.

- spam is sent in your name and you get accused of sending spam or
spamvertising sites, while you are in fact clean; it may even get your
webpage or hosting account temporarily suspended until the issue is
resolved (something that happened to a few of our customers), not to
mention time is wasted by all parties involved, all the while human
labor nowadays tends to be much more costly than machine "labor"

Which do you choose?

>
>> I work at hosting company, and not only I don't mind e-mail addresses at
>> our site being verified by call-outs, but in fact I would welcome more
>> of them: this reduces the chance that spammer or other fraudster sending
>> mail that has domain of one of my users in the SMTP envelope to the
>> server that uses sender verify w/callouts.
>>
>> More than once I had bad blood caused between link providers, customers
>> who aren't experts at issues of combined e-mail/DNS/online fraud areas
>> (they think that sender address on envelope in e-mail actually means
>> something) and our company because some spammer or fraudster used e-mail
>> address belonging to one of our customers to send spam or fraud. Had the
>> servers that were spamming target used callouts to MX for that customer,
>> that spamming wouldn't have happened, and we would be very happy to be
>> "burdened" with that miniscule cost of verifying e-mail addresses of our
>> customers at our hosts.
>>
>
> There is already an SMTP verb for such activities: VRFY. It is normally
> disabled.
>
I'm afraid spammers would quickly abuse VRFY, namely its low cost.
Besides, IIRC VRFY does not give conclusive reply but only "I don't know
if this address is valid", right?

> That being the case, using RCPT to perform the same function (check an
> address) seems to be working around a deliberate decision of the operator
> of that system, so you can see how it is considered abusive.
>
That's just a short step from saying that using RCPT to send them mail
is abusive. Why do they expose MX on internet for their domain if they
don't want it to be used? That it is not used _exclusively_ for sending
mail to them which seems to be their intention, but that it is also used
for verification whether particular address exists at their domain,
which may not be exactly their intention?

It's a bit touchy and kind of obstinate in my view: we have spam
overflowing our mailboxes, but we worry about a few RCPTs, using which
after all is completely in agreement with SMTP protocol (I mean there's
nothing in protocol that says RCPT TO and then QUIT should not be done)
and most users never even see them, let alone care about them (while
they tend to care about quantities of spam they get)?
> Let those who want to allow 'callouts' to work enable VRFY and encourage
> others to use that. Let those who don't want callouts keep VRFY disabled
> and not have to tolerate subversion of RCPT.
>
> It has often been observed that people's position on this matter
> changes once it is their own domain which gets forged as a sender in a
> million-spam run, and they have to deal with the callouts ...
>
They kind of overlook the other side of the coin: that spam with their
domain would be sent to a respective million of addresses and this could
cause them a lot more trouble. Not to mention that million of spams sent
to _someone_, that callouts in this particular case would have blocked.

If they expose their address, hosts, and MX for communication, they
should not complain someone is using their hosts in protocol-compliant
way to verify whether mail sent in their name really originated at their
place. They should rather be happy about it enhancing their viability /
preventing indirect damage to them.

If there's better solution around, I'm all for it. I just don's see any,
and my estimations indicate the volume of spam rejected as result of
callouts exceeds the volume that filters like SA identify at least six
times. Isn't it kind of positive side effect for everyone? Spam is a
sort of "tragedy of the commons" problem, and nothing out there seems
good solution, while callouts reduce it.

Consider also the other situation of those people who don't like their
addresses verified: they don't like bearing miniscule cost of spam being
prevented when mail is sent to them, but they sure would like their
e-mail operator to use callouts to MXes for OTHER people's domains,
because they would like to get less spam after all, wouldn't they?

Frankly, callouts should be normal part of SMTP standard, and everyone
should just pay the (laughable) costs of it, use it to verify others and
allow others to verify their domains, and be happy that it works so well
in reducing spam.

--
Marcin Król