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 -- ## List details at http://www.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://www.exim.org/eximwiki/
