In message <v04003a01b1ea9bad0a10@[207.34.64.181]>,
Grant Neufeld <[EMAIL PROTECTED]> wrote:
>Here are the relevant parts from a new internet-draft I'm preparing. The
>working form of the document itself can be found at
>http://www.nisto.com/listspec/#DOCUMENTS
>
>Please address all follow up to the list-header mailing list
><[EMAIL PROTECTED]> <http://www.nisto.com/listspec/mail/>,
>or to me privately. Thanks.
>
> The List-Probe Message Header Field for
> Identifying Mail List Probe Messages
>
>Abstract
>
> This document defines the message header field "List-Probe"
> to be used in consistently identifying mail list probe messages.
>
>
>1. Introduction
>
> Many MTAs (mail transfer agents - mail servers) in use today do not
> provide adequate details when failing to transfer mail messages. In
> particular, when email is automatically forwarded from a recipient
> address to a second address that is 'bouncing' incoming mail, the
> error response messages may not properly including the original
> (forwarding) recipient address.
>
> To help deal with this problem, many mailing list managers have taken
> to sending out individualized "probe" messages. The probes include
> enough identifying information - even if the original recipient
> address is not included in the error response - that the forwarding
> address can be properly identified.
>
> The drawback to this approach is that valid recipients will receive
> the probe messages in their mail - an unfortunate waste of time and
> resources.
>
> This document defines a message header field, List-Probe, which will
> allow MUAs (mail user agents - email clients) to identify and
> automatically discard probe messages so the user does not have to be
> involved in the process. If a probe message is received by a MUA,
> the recipient address is valid, so the probe does not need to be
> responded to (and can safely be discarded) since probes are only
> seeking error responses.
A question if you don't mind...
Isn't this basically the exact same sort of facility that the SMTP VRFY
command is supposed to provide? If so, why write a new RFC? Why not
just get people to implement the old one(s)?
It seems to me that a lot of people out there disable the VRFY command in
their MTAs out of a misplaced concern for ``security''. So even if you
come up with a new way of verifying addresses as being really and truly
alive and active, won't people just disable _that_ also?
-- Ron Guilmette, Roseville, California ---------- E-Scrub Technologies, Inc.
-- Deadbolt(tm) Personal E-Mail Filter demo: http://www.e-scrub.com/deadbolt/
-- Wpoison (web harvester poisoning) - demo: http://www.e-scrub.com/wpoison/
