Keith Moore <moore@cs.utk.edu> writes:
# Steve Simmons <scs@lokkur.dexter.mi.us> writes:
#
# # I'd like to propose a mechanism and a very small, very tight RFC.
# # The mechanism is a new set of headers - List-Unsubscribe and List-Admin.
# # (We can start using them now as an experiment by putting X- forms if we
# # like.) The header would be something like
#
# at one time I suggested something similar, except that the notation
# was flexible enough to indicate what text you should send to the
# list server, to accomodate different software. so for na-net you
# could do:
#
# List-unsubscribe: rcpt=na.remove@na-net.ornl.gov;
# body="firstname: ${firstname}\nlastname: ${lastname}\nemail: ${subscriber}"
#
# whereas for listserv it would be
#
# List-unsubscribe: rcpt=listserv@foo.bar.com; from="${subscriber}";
# body="unsub ${subscriber}"
#
# and for a human-maintained list it would be
#
# List-unsubscribe: rcpt=foo-request@foo.bar.com; from="${subscriber}";
# body="please remove me from the ${listname} list!"
#
# finally, there were also methods for subscriptions and change-of-address,
# so you could publish them in a globally-accessible database (i.e. not
# just for people who are already on a list!)
#
# yes, I think the time is right for such a thing. if nothing else it
# would help improve the accuracy of the various service providers'
# auto-subscribe interfaces, since the list maintainers could just
# advertise their list data (say, to comp.mail.lists?) and the service
# providers could just parse it.
Is there any way we can merge all of this (subscribe, unsubscribe,
whatever) into one multi-line header, and keep it under 1024 bytes
total? I think we'll face less resistance from MUA authors if it's
only one header, instead of N headers.
-Brent
--
Brent Chapman | Great Circle Associates | Call or email for info about
Brent@GreatCircle.COM | 1057 West Dana Street | upcoming Internet Security
+1 415 962 0841 | Mountain View, CA 94041 | Firewalls Tutorial dates
Follow-Ups:
|
|
