So why not use a callback instead? [LWN.net]

So why not use a callback instead?

Posted Sep 6, 2004 7:10 UTC (Mon) by leonbrooks (guest, #1494)
Parent article: Debian rejects Sender ID

email arrives at your server (A) by the normal process of connect, HELO, MAIL FROM, RCPT TO - and we halt the process at this point;
A looks up the MAIL FROM address as if it was going to send email there; if there is no appropriate server records, this is spam - return a permanent error (555 sender email domain does not exist?), goodbye, and maybe mark the sender IP as a possible spammer;
A now connects to the nominated server(s) (at B); if it gets a temporary error, it also returns a temporary error (333 sender SMTP server unable to verify address?), and if it gets a permanent error it returns one (555 you don't exist so we're sending your details to the FBI);
A now walks through the process of sending mail to B, from a special address or range of addresses which "know" about callback, and if B refuses to accept it, returns a permanent error (555 originating email address is refusing a response?);
If B accepts everything up to and including DATA, we drop the connection, casuing B to discard the message;
If while faux-sending to B, A sees inbound email from B to a special address, it ACKs the incoming mail and discards it; if the sender actually delivers a message then both it and the original message are rejected (555 callback elicited excessive response?) instead.

Spammers can still set up fake inbound servers to "accept" callback checks, but it gives anti-spam software an extra address to correlate against and/or block, and represents additional discouraging work for the spammer.

Also, if the spammer is using an internet connection which bills them for traffic recieved, this starts to cost them. Especially if you're not charged for outbound traffic, and elect to respond to spam by portscanning the originating IP and sending back (say, for a DSL connection) 10000 copies of a 100kB randomised do-not-spam-me message for each inbound connection attempt from the spammer.

If 1% of mail servers did this, the spammer would get back 100x the traffic that they send and would have no idea whether any of the portscans are for real. Since some spamming software chops the internet link when it sees an incoming portscan it will slow down their work tremendously and possibly increase the outlay too, and if they're running an auto-IP-blocking firewall the portscan causes the spammer's own firewall to protect you against them - and if they're not, your email server can tell you that, too.

to post comments

So why not use a callback instead?

Posted Sep 6, 2004 9:13 UTC (Mon) by lolando (guest, #7139) [Link] (3 responses)

Assume I'm a spammer. Like my fellow spammers, I don't send e-mail from my own hosts but from open relays. I therefore register the whatever.com domain, host its name servers, and make its A/MX records point to some poor sod's open relay (that would be B by your notation, if I understood it correctly). Your A receives an email from my B (appearing to be from foo@whatever.com), double-checks everything, and proceeds to deliver it, or not (that will depend on how B is set up, I suppose). In any case, I have used very little of my own bandwidth.

Maybe I missed something.

So why not use a callback instead?

Posted Sep 6, 2004 10:02 UTC (Mon) by frankie (subscriber, #13593) [Link] (2 responses)

SPF-like protocols are not universal panacea. SPF just blocks forged addresses, like those used by a few spammers and worms.
Many other spammers use fictious domains (with good SPF records)
and pass anyway. The same thing could be done by worms potentially.
So SPF complicates life of normal users (who cannot use regular forwarding)
and have very little impact on true spammers who have methods to by pass it.
I see no evidence that Sended-Id is better...

So why not use a callback instead?

Posted Sep 6, 2004 10:58 UTC (Mon) by sdalley (subscriber, #18550) [Link]

If by a fictitious domain you mean a domain that does not exist, then DNS lookup would not be able to obtain DNS records of any sort. Or do you actually mean something different?

Why no network of trust?

Posted Sep 7, 2004 14:53 UTC (Tue) by forthy (guest, #1525) [Link]

It is not obvious for me that you can't add a network of trust to a
SPF-like framework. Like S/MIME or PGP, SPF records would need a signature
(or several signatures, if you like). If you create your domain, the NIC
usually would also sign your SPF record; done. Since domain creation is a
hierarchical situation, tracing signatures back to some known good "root"
signature is not really difficult.

In the end, this does not help bot-based spam networks and worm floods.
Even if you require the user to enter a passphrase for every outgoing
mail, an infected PC could grab that passphrase and send spam and worms
under the name of the victim. However: It is now possible to help the
victim, since you can identify her (or him). Part of the success of
captured computers is that the user doesn't know about it.

So why not use a callback instead?

Posted Sep 6, 2004 10:25 UTC (Mon) by neilbrown (subscriber, #359) [Link]

This is often referred to as "CBV" - call-back-verification.

The "from" address that is normally used is "<>". For other addresses it is possible to get false rejects.

The problem with this is that it allows an untraceable DOS attack. If some malcontent sent spam from thousands of "owned" machines all claiming to be from <axxx@my.domain>, then if all the recipients of that spam did CBV to my mailserver, it might be a very serious hit coming from genuine mail servers.

This may be a spectre rather than a real problem, and I'm seriously considering implementing it. However it doesn't really help stopped fakes or unwanted mail, at least not in the long run. It would server to keep the queue of outgoing bounces short though.