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
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg