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

From: Brett Watson <[email-masked]>
Date: Wed, 1 Oct 2003 15:21:28 +1000

There has been some discussion of pull-based mail on the list recently. I'd 
like to mount a brief defence of the "pull" concept at its most general 
level, rather than the specific application of it that has been bandied about 
(push a notification).

Consider a variation on SMTP where the DATA phase is replaced by the sender 
passing a token which allows the recipient to call the sender back and pull 
the message data when it is ready to do so. This has the following 
advantages.

1. An open HTTP proxy is no longer a sufficient tool for the distribution of 
spam, as the callback will fail. A fully compromised host (zombie) can still 
be employed as an MTA, but any intervening firewalls which block incoming 
connections will spoil the attempt, and the host's effectiveness will be 
seriously limited by the time it spends online, since it can't choose when 
the callback connections will arrive.

2. The mail system currently allows the sender to take an entirely active role 
in the process. It is desirable to reduce the sender's overall power in the 
mail transfer process, since senders are the more problematic party, and 
assigning them a more passive role is one way of moving towards this end.  A 
shift from "push" to "pull" is one obvious consequence of this approach.

3. "Pull" is a perfect match for "greylisting". In a push-based system, the 
recipient must temporarily refuse the message until the timeout period has 
passed. In the case of a pull-based system, the recipient merely delays the 
pull attempt until such time as it is ready. In a pull-based system, the 
timing of the message fetch is primarily under the control of the recipient 
(as it should be: refer point 2). All modes of "hit and run" spamming are 
diminished in effectiveness by greylisting, and "pull" facilitates 
greylisting.

4. There is no significant cost to the sender to implement this, as opposed to 
a "proof of work" system or payment system. Compliant SMTP systems must 
already deal with message queueing: the "pull" approach merely hands off the 
timing of message transfer to the recipient. This can even offer a slight 
efficiency advantage in cases where the recipient's mail-store is full (or 
similar), since the recipient is in the best position to know when it's able 
to receive the message.

Note that I only suggest this mechanism for use in the case of "inter-domain" 
mail, where no prior trust relationship exists between MTAs. I don't see it 
as useful in the case of mail submission from an MUA to an MTA.

I further investigate the smallest set of modifications to SMTP that would be 
required to support "pull" in section 4 of my honours thesis (dated July 
2002) at the following address.

  http://www.comp.mq.edu.au/~brett/bschons/part4.html

Regards,
TFBW

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Brad Knowles <[email-masked]>
Date: Wed, 1 Oct 2003 09:46:29 +0200

>  diminished in effectiveness by greylisting, and "pull" facilitates

	In essence, this would be like asking recipients to go to the 
remote post office box for each and every sender, when they wanted to 
pick up mail.  On the Internet, this isn't as bad as it would be in 
the real world, but it would still be exceptionally painful. 
Moreover, while envelope-based filtering would be made easier, body 
content filtering would still require obtaining the message body and 
then looking at it.

	Until you can provide mechanisms that have strong cryptographic 
authentication that securely tie in a particular notice to a 
particular message body, and you can ensure that it is physically 
impossible for someone to accidentally or intentionally swap message 
bodies, I don't see where you can get this mechanism to work.

	There's a reason why the envelope is delivered along with the 
message body, even if the entire envelope is a forgery (beyond the 
source and recipient addresses).  For MTAs that split the envelope 
from the message body, they have to deal with a two-phase commit 
problem to keep the two in sync.  That makes the problem 
significantly more difficult to deal with.

	Now you're talking about not only splitting the envelope and body 
into two separate files, but into two completely separate 
transactions.

-- 
Brad Knowles, <[email-masked]>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
     -Benjamin Franklin, Historical Review of Pennsylvania.

GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)

---

From: Brett Watson <[email-masked]>
Date: Wed, 1 Oct 2003 20:00:38 +1000

> the real world, but it would still be exceptionally painful.

I'm not quite sure which "recipient" you mean: I was referring to the 
receiving MTA in a mail exchange between domains with no prior trust 
relationship. The receiving MTA would pull the message from the sending MTA 
and deliver it to the message repository (subject to policy) in a way that is 
transparent to any agent or person beyond that point.

The analogy you give is technically accurate, but you could also describe the 
existing situation as like hanging around in a well-advertised location all 
day and night just in case someone wants to talk to you. It makes it sound as 
though a person is being inconvenienced, when all we are talking about is a 
computer program (the MTA).

> bodies, I don't see where you can get this mechanism to work.

I don't see that this argument applies. It is possible to require the sender 
to commit to a particular message by including the SHA1 digest (or similar) 
of that message as part of the callback token, but I don't see that it gains 
us anything in this instance. The receiving MTA is expecting some arbitrary 
message. It is possible, in this instance, that the message could be changed 
between the receiver being told about it and actually fetching it, but what's 
the associated threat? I changed this message several times before anyone 
else saw it -- what's the difference?

> significantly more difficult to deal with.

I think we may be confusing our vocabulary here. I understand "envelope" to 
mean all the metadata associated with the SMTP dialogue, and "message" to 
mean the information passed in the DATA phase of SMTP, which is supposed to 
conform to STD 11 (RFC 822 and its successors). The message consists of a 
"header" (or "header fields") and a "body". This is the terminology used by 
RFC 2822 (see sections 1.1 and 2.1).

I can't comprehend your remark, "even if the entire envelope is a forgery 
(beyond the source and recipient addresses)", except by assuming that you 
meant "message header" rather than "envelope", since the "MAIL From:" and 
"RCPT To:" addresses are basically all there is in envelope data. But if I 
make that assumption, I can no longer see the relevance of your remark to my 
argument at all, since I've said nothing about separating the message header 
from the message body: the whole message is pulled in a separate session.

Perhaps you could explain the nature of the two-phase commit problem in a 
little more detail?

Regards,
TFBW

---

From: Brad Knowles <[email-masked]>
Date: Wed, 1 Oct 2003 12:55:27 +0200

>  transparent to any agent or person beyond that point.

	Okay, then.  Remind me what the benefit is that you're trying to achieve?

	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.

	Message content decisions can only be made once the message 
content has been received, regardless of how that transmission 
occurs.  Again, no change to the protocol is required.

	Greylisting does not affect these issues in any way, nor is it 
impacted by them.

>  else saw it -- what's the difference?

	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.

	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.

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

	Otherwise, once you've posted your reply the sender could then 
change the text it appears that you're replying to, which might 
change the whole tone of the discussion -- instead of violently 
opposing cruelty to animals, you are instead seen as violently 
opposing respected charities beneficial towards animals.

	This also implies that the original stored message content is 
unrecoverable by the recipient, if they didn't check the message 
before the content changed.  All they'd have is an SHA-1 digest that 
tells them about a message that supposedly existed for them, but it 
is no longer available.

	You might be able to create a chaining mechanism, which says that 
message body with hash X was replaced by message body with hash Y, 
but unless you require the "message pull" storage server to keep a 
copy of each and every version of each and every message body, you 
would have no way to know what was in any of the previous versions of 
the message.

>  Perhaps you could explain the nature of the two-phase commit problem in a

	Sorry, I was thinking that you were talking about splitting the 
headers from the message body.  My bad.

---

From: Brett Watson <[email-masked]>
Date: Thu, 2 Oct 2003 02:07:43 +1000

> 	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.

> 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.

> 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.

> determine whether or not the message body has changed since the

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.

> 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

---

From: [email-masked] (Justin Mason)
Date: Wed, 01 Oct 2003 10:05:00 -0700

> causing delivery failure.

Note that HTTP reverse-proxies *are* already being used by at least 1 spam
gang to shield their spamvertized websites.

Ie. they set up the spammed website on their hosting somewhere, then
preload its content into several open web caches [1].  They then change
the DNS record for that website to point to the caches, with a low TTL so
they can switch it to the next cache when the proxy gets shut down.

"Pull" methods should try to consider if this would still be workable.  If
it would, it's not a big deal for spammers to all start using that
technique.

([1]: I'm not entirely sure how this is done off the top of my head right
now. ;)

--j.

---

From: Brett Watson <[email-masked]>
Date: Thu, 2 Oct 2003 03:54:26 +1000

> gang to shield their spamvertized websites.

This is true. Some documentation on an instance of this can be found at the 
following site.

  http://www.lurhq.com/migmaf.html

> it would, it's not a big deal for spammers to all start using that

I expect that the "pull" technique would connect back to the IP from which the 
SMTP session originated. There may be other possibilities, but this seems 
like the safest and most reasonable protocol, for the purposes of this 
discussion, at least. It has the benefit of minimal difference to the 
existing "push" case.

Under these circumstances, a reverse proxy can work, but the DNS tricks used 
in the case of reverse proxying a website won't have any effect (since no DNS 
lookup is necessarily involved). The effectiveness of the proxy will be 
limited by the amount of time the compromised machine stays online and 
available at a given IP address, having sent an envelope, relative to the 
average time to callback.

So pull-mode delivery doesn't defeat this outright, but it's not friendly to 
it. I believe it's fair to say that it would shift the cost/benefit ratio of 
spam significantly in our favour without harming legitimate mail.

Regards,
TFBW

---

From: Brad Knowles <[email-masked]>
Date: Wed, 1 Oct 2003 21:57:32 +0200

>  ([1]: I'm not entirely sure how this is done off the top of my head right

	DNS Cache pollution/poisoning.  Jon Postel did it accidentally in 
the mid 90's, and Eugene Kashpureff did it again in 1997, and many, 
many servers remain vulnerable.  At last survey, over 50% of the 
ccTLD servers were vulnerable to cache pollution/poisoning, which 
would imply that a much, much higher percentage of "regular" 
nameserves are likewise vulnerable.

	See <http://www.shub-internet.org/brad/papers/dnscomparison/>. 
I'm sure Men & Mice has some numbers, too.

---

From: Brad Knowles <[email-masked]>
Date: Wed, 1 Oct 2003 21:51:46 +0200

>  a convenient way for a spammer to hide behind someone else's IP address.

	With you so far.

>  causing delivery failure.

	I disagree.  In the case of zombies, which is becoming more and 
more the method of choice, they have complete control of the machine. 
They can send out the notices, wait for the callbacks, and then send 
the payload.  All safe in the knowledge that they control the 
machine.  Moreover, a network of zombies could easily be configured 
so that one zombie designates another as the call back server, and 
that process could even be distributed and load-balanced.

>  time.

	Many spammers and viruses are already doing two rounds of 
attempts on the same recipient addresses.  They don't actually queue, 
per se, in that they have only one copy of the message body and they 
do a mail-merge to the massive group of recipients (allowing them to 
operate entirely out of memory for maximum speed), but they do track 
status for the recipients and retry failures.

>         Many spamming tools seem to work the same way: spammers compensate for

	See above.  Greylisting is currently working for a certain 
percentage of messages, but that percentage is rapidly decreasing. 
It will continue to be a valid useful tool in the future, but only in 
conjunction with other tools, especially message content 
scanning/central registry tools such as DCC/Vipul's Razor/Pyzor, and 
realtime per-IP address spam-reporting/blacklist tools.  Greylisting 
gives them a much better chance of being able to catch and quarantine 
messages based on reports from other people.

	The next phase will be to rapidly change the message bodies fast 
enough so that DCC/Razor/Pyzor become less and less useful.  Same for 
realtime IP address reporting/blacklist tools.

>  it."

	That only affects the overall issue when done end-to-end.  If you 
try to slot this in at the link layer, it doesn't help.

	If telemarketers have to call a number and leave a message for a 
callback but you are not in direct control of that callback, you are 
no better off than if they had called you directly.

>  your own time.

	Envelope checks happen quickly anyway.  If you're getting so many 
of them that you bog down doing them interactively, then you're not 
likely to have your situation improved by accepting everything and 
then trying to do them in the background.  If anything, you're likely 
to be put in a worse position, as you get overrun by spam and viruses 
and you can't properly deal with the real messages.

	With both spam and viruses, you're best off if you can detect 
them interactively and refuse to accept them in the first place.  If 
the sender manages to successfully transmit the message to you 
without being detected, they've won.

>                  Timeout constraints are relaxed by at least an order of

	If you want to do background mode for envelope checks, it could 
always be a fallback from interactive mode, although I still believe 
that it's a bad idea.

>  problems than the scenario you mentioned, regardless of your mail transfer

	Yeah, but you've also given them a much bigger target.  Why do 
criminals still go after banks, even with all the security, guards 
with guns, and everything else?  Because that's where the money is.

	You're concentrating by many, many orders of magnitude the 
attractiveness of the target.  You're also concentrating by many 
orders of magnitude the amount of reliability that has to be provided 
by that server.  It is not only responsible for storing messages 
temporarily while they are being transmitted, now it also has to hold 
all those messages while they're waiting for callback.

	Moreover, for spammers or viruses, for the callback they can 
always designate another server they control, or themselves.

>  unsatisfactory for some reason?

	It's yet another change to the protocol that has to happen, 
because you're trying to change the fundamental nature of the way 
e-mail works.  It's a patch to an already bad patch, and that doesn't 
improve the situation.

>  can be sensibly built onto the pull-mode base if they are considered

	They would be necessary, but you would need to make them even 
more complex because you'd have to deal with things like changes in 
the content-transfer-encoding which change the internal 
representation of the message, but not the actual content of the 
message itself.

	This is the same sort of problem that PGP-signed messages have 
today.  Think about how many mailing lists there are which still 
break PGP signatures, not to mention less intelligent MTAs, etc....

>  more robust against many mail-abuse techniques:

	I don't think you've successfully shown that.  Many times there 
are methods which are suitable at the link layer that are not 
suitable for end-to-end, or vice-versa.  Using a pull-based mechanism 
has been demonstrated to work for USENET and web discussion groups.

	But you have yet to prove that you can successfully use this 
end-to-end mechanism to any benefit for the link-layer (especially 
since most e-mail is point-to-point today anyway), or that you can 
successfully turn all Internet e-mail into USENET news or web 
discussion groups.

---

From: "Dag Kihlman" <[email-masked]>
Date: Thu, 2 Oct 2003 23:49:11 +0200

----- Original Message ----- 
From: "Brad Knowles" <[email-masked]>
To: "Brett Watson" <[email-masked]>
Cc: "Brad Knowles" <[email-masked]>; <[email-masked]>
Sent: Wednesday, October 01, 2003 9:51 PM
Subject: Re: [Asrg] 6. Proposals - A Brief Defence of "Pull"

> that process could even be distributed and load-balanced.

In a pull system the mail must be pulled from one special IP address. It
could be on top of a distributed and load balanced system, as you say, but
it must keep that IP address or the mail will not reach the recipient. That
is the nice thing with a pull system. You get an IP address that must be
valid and together with an efficient real time blacklisting system it would
work very well. It is true you do not need a pull system to have a blacklist
but since the IP address must be valid a longer time the blacklist works
best together with a pull system.

I agree fully when you say that some pull servers will be attractiv to hack.
In a pull system the best way to avoid blacklists is to hack pull servers.
With SMTP you do not have to do it, it is a complete waste of time. That is
why I suggested encryption. If the mails are encrypted and the key trown
away there will be no point in hacking the pull server. After "decryption"
the mails will be unreadable. :-)

/DK

---

From: Brad Knowles <[email-masked]>
Date: Thu, 2 Oct 2003 01:58:58 +0200

At 11:49 PM +0200 2003/10/02, Dag Kihlman wrote:

>                   It is true you do not need a pull system to have a blacklist

	The same can be said for existing use of greylisting plus an 
enforced delay before you will accept the message, in combination 
with black lists and message content reporting systems.

	You offer no advantages here, for all the extra costs you would 
be imposing.

>  the mails will be unreadable. :-)

	It is sufficiently difficult to properly implement cryptographic 
message signing, much less message encryption.  Moreover, the 
existing systems implement this sort of thing where the spare CPU is 
most available -- on the client.  You would be increasing by untold 
orders of magnitude the amount of message encryption that would be 
required (above what is happening today), and you would be doing it 
centrally -- the one place in the architecture that has the biggest 
CPU crunch already.

---

From: Brett Watson <[email-masked]>
Date: Thu, 2 Oct 2003 15:11:42 +1000

I started writing a point by point response to the previous message in this 
thread, but abandoned it halfway through as it appeared to be degenerating 
into extreme silliness. I'll therefore make a brief "closing argument" 
instead.

In the fight against spam, it is worth considering the use of a pull-based 
transfer of data at some point in the protocol for the following reasons.

1. It defeats the exploitation of open HTTP proxies and other one-way address 
hiding schemes; the sender must take a server role.
2. It can act as an improvement over greylisting, since the recipient is in 
control of the callback attempt, rather than waiting passively.
3. It could be incorporated into SMTP in an evolutionary manner if desired.
4. It need not present significant new exploit paths for spammers.

Brad Knowles has raised many objections to my defence of "pull" in this thread 
so far, quite a few of which I have left unanswered. I intend to leave them 
that way: I disagree with them, but addressing them would probably get me 
nowhere with Brad, and bore the remainder of the list. Therefore, I rest my 
case.

If anyone (other than Brad) feels that my argument is weak in some way, I'll 
be happy to consider the issue, either off-list or on.

Regards,
TFBW

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 02 Oct 2003 01:25:33 -0400

> be happy to consider the issue, either off-list or on.

KEEP IN MIND that pull is being considered for many applications that 
were prior carried over email such as newsletters which begun to migrate 
to HTML and RSS. If anyone considers the "pull" proposal viable for 
specific applications or even for email, then a document summarizing 
pros and cons would be useful. This document should include input from 
both side of fence and take the req. and tech. considerations document 
into account.

However, keep in mind that "pull" proposals and other "replace SMTP" 
proposals are a long term solutions. There will be too many issues 
deploying it short-term.

And Brad and Brett - thank you for keeping your cool! In the past many 
conversations like this have deteriorate into flame wars. This is a mark 
of improvement for the entire group.

Yakov

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 02 Oct 2003 01:26:02 -0400

Yakov

---

From: Brad Knowles <[email-masked]>
Date: Thu, 2 Oct 2003 10:55:10 +0200

>  nowhere with Brad, and bore the remainder of the list. Therefore, I rest my

	I will agree to disagree.

	I've been biting my tongue with regards to most of the RMX-like 
proposals because most of what I would say would simply be a re-hash 
of things already said.  I will do the same here.