On Thu, Mar 31, 2005 at 10:37:12AM -0800,
ned(_dot_)freed(_at_)mrochek(_dot_)com wrote:
An implementation might know the address being delivered to (the
envelope recipient). UNIX "vacation" has a place to put additional
email addresses to look for, because the envelope recipient has
typically been been lost at this point. I would say that that's also
the value of the ":addresses" here too.
So I would think this would say that the envelope recipient, if known,
OR one of the addresses listed in the :addresses must appear in one of
the listed header fields.
I really don't think a change is in order here. Nothing in the present text
makes an implementation that has no knowledge of its own of the recipient's
address(es) incompliant. And OTOH I really don't think we should encourage
implementations that are ignorant of this. (It is one thing when
circumstances
make it impossible, quite another where a standard in effect condones lazy
implementation practices.)
I humbly beg to differ about the lazy part.
Please reread my response more carefully. At no point did I say, or even imply,
any laziness on your part. On the contrary, I fully acknowledged that there are
going to be cases where the implementation won't know what all, or even some,
of the addresses asssociated with the recipient are. And this is the primary
reason for having an :addresses argument - so specific scripts can
specify those addresses the implementation does not know about.
But this is information is available to lots of other implementations. It may
take a little work to dig it out, but it is there all the same. Weakening the
requirements to a MAY gives license to to these implementations to not to the
work to be as good as they are able to be. And that's just bad
standards-making, especially when what we are dealing with is a facility which
when done badly will engage in bad behavior like sending useless crap to lists.
While I am probably lazier
than the next guy, I'm talking about completeness here in the absence of
knowable information. Remember (as I'm sure you do) that we're talking
about looking into the various destination headers (To, Cc, et al) to
make sure that one of them contains one of the addresses owned in some
sense by the recipient, as an indication that the message is specifically
addressed to the recipient.
There are a number of legitimate reasons why the implementation might
not know what all of the specific recipient addresses are.
...
Of course there are. You are beating a straw man here.
Now, perhaps your point is that neither implementations nor the
script constructors will have information regarding the recipient's
actual email addresses. In such a case there is indeed a problem. But
the benefit of solving this problem has to be weighed against the cost
of not having the check. And past experience with vacation mechanisms
says that these checks are very important to have.
In any case, since RFC 3834 only makes this a SHOULD-level thing, I guess I
could live with changing the MUST to a SHOULD if there's a consensus
to do so. I'm not seeing the consensus, however.
So back to the specific recommendation: if you have the envelope
recipient address available, IMHO the spec should allow you to make use
of it in this test;
"Allowing it" equates to a MAY, and a MAY is a violation of RFC 3834.
I think there is broad agreement that we need to be at least as stringent
as RFC 3834.
it would likely be the prime address to find in one
of the recipient-address header lines. I can't see why this is any
less valid than using some other notion of the recipient's email
address: if the message has made it to the point where it's being
processed by the recipient's script, the envelope recipient address *is*
one of the recipient's email addresses. Are there downsides? What
are they?
Nothing in the draft prevents you from using the envelope recipient
address as basis for this comparison, so I guess I don't understand
why this solves anything. I suppose I could add some text about the
possible use of the envelope recipient address to determine the
recipient's address, but it seems, well, obvious.
Ned