ietf-asrg
[Top] [All Lists]

Re: [Asrg] 6. Proposals - A Brief Defence of "Pull"

2003-10-01 09:09:33
On Wed, 1 Oct 2003 20:55, Brad Knowles wrote:
      Okay, then.  Remind me what the benefit is that you're trying to 
achieve?

I thought I made that clear in my first message, but apparently not. I'll try 
again, but aim for practical examples rather than philosophical principles 
this time.

A large volume of spam is currently shifted through proxy servers: either 
misconfigured HTTP proxies, or virus-compromised PCs with added malware 
(zombies) [ref. http://article.gmane.org/gmane.ietf.asrg/6061]. They provide 
a convenient way for a spammer to hide behind someone else's IP address. 
Requiring a callback to fetch the message data makes this approach much 
harder for a spammer, as it would require proxies in both directions: an HTTP 
proxy will not suffice at all, and the longer the callback is delayed, the 
more likely a zombie will have gone offline (at least temporarily), thus 
causing delivery failure.

Consider viruses which propagate by means of their own SMTP engine: by far the 
most common variety, as I understand. They distribute themselves 
opportunistically, relying on immediate delivery; if they encounter a 
temporary failure, they just move on to the next target rather than wasting 
time. Many spamming tools seem to work the same way: spammers compensate for 
delivery failures by attempting delivery to a larger number of addresses, 
rather than sitting around and waiting for the mail to get through to 
unresponsive sites. This is why greylisting works [ref. 
http://projects.puremagic.com/greylisting/].

The "pull" mode of delivery complements this very well, because in a pull-mode 
delivery, the receiving system controls the timing of delivery. Greylisting 
is like saying, "if you're serious about sending me this message, call me 
back later." Pull-mode delivery is like saying, "if you're serious about 
sending me this message, let *me* call *you* back later, when *I* feel like 
it." It puts more control of the process into the hands of the recipient, and 
greater recipient control is what we chiefly need, since recipients are the 
victims. It also places greater responsibility on the sender, since they must 
operate a server in one place long enough for you to call it back.

      Pure envelope decisions could be made before the message body is
transmitted, regardless of how that transmission occurs.  No change
is required to the protocol.

Indeed, but you are under modestly significant timeout constraints if you want 
to pause to check various things in the middle of an SMTP dialogue. With 
pull, you can accept the envelope data, then do your policy checks on it in 
your own time. Timeout constraints are relaxed by at least an order of 
magnitude, and you're not holding a TCP connection open while you do it, 
either. So there is a benefit here, albeit a relatively minor one.

      You give spammers a new avenue of attack.  All they need to do is
compromise a "message pull" storage server, and replace the message
bodies there with their spam.  The notifications that were originally
sent out were perfectly legitimate, but the message bodies that the
recipients get are bogus.

The "message pull" storage server is an outgoing MTA -- one that normally acts 
in a role of accepting SMTP connections from your network and doing a 
store-and-forward to the remainder of the Internet. It may also be an 
incoming MTA. If spammers have compromised it, you have *much* bigger 
problems than the scenario you mentioned, regardless of your mail transfer 
protocol.

      You have to be able to guarantee that the recipient (MTA) can
determine whether or not the message body has changed since the
notice was sent.

I still don't see that this is a realistic threat, but as I said, the sending 
MTA can pass a SHA1 digest with the envelope data, and thus commit to a 
message in exactly the manner you desire. Or would that still be 
unsatisfactory for some reason?

A SHA1 digest would provide an additional DCC-like data point to evaluate as 
part of the policy check, and I can see some value in that. The sender could 
also commit up-front to a message size, and that would be useful. Both of 
those data points can be verified after download, and the message rejected 
due to "data corruption" if the checks fail. These are additional ideas which 
can be sensibly built onto the pull-mode base if they are considered 
valuable.

      Moreover, this requires that the stored message bodies can only
be used unidirectionally.

From this point on, I'm afraid that you lost me again. I think you're arguing 
against a scheme that someone else proposed. I'm attempting to argue that the 
smallest possible addition of pull-mode behaviour into SMTP would make it 
more robust against many mail-abuse techniques: that's all. Once a message 
has been pulled, I expect the sending MTA to delete it, just as it 
(presumably) does for a successful push-mode delivery. The same old 
store-and-forward model applies, just with the recipient taking a more active 
role.

Regards,
TFBW


_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg