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