I'm going to stick with my opinion and "agree to disagree" because
although everything you say may be true, my experience suggests
otherwise. The issue is that of false positives.
I used to do what you describe but the algorithm got it wrong once, or
at least one time that was brought to my attention. Not because the
algorithm was buggy but because assuming "." is a separator between pure
localpart and subaddress is wrong. I also had some strange experiences
with "/" in "X.400" addresses, but that may be moot today. The downside
of getting it wrong may only be annoying, in general, but as a service
provider I can not afford to be annoying.
In my opinion it does take rocket science because you're making semantic
assumptions with no foundation whatsoever.
I called it illegal because a localpart should be opaque outside its
local environment. I tried to find a reference to this effect in some
standard but couldn't. It may just be "practiced wisdom" but I can not
remember a time when it wasn't true.
You more or less got me on the case sensitivity issue. I also agree
with your assessment that most filtering practices incorrectly do case
insensitive comparisons of localparts. However, as a practical matter,
I think this is one of those issues where you have to be "liberal in
what you accept, conversative in what you send."
I'm very careful to retain case settings (got that wrong once, too, many
years ago) and I do case insensitive comparisons of localparts, but only
after the domains match. This doesn't make it right, but I'm also
careful to note duplicates so if there were two subscribers with the
"same" localpart but with different case settings, it would get noticed
immediately. Thus, in this case, I have a fail-safe so I'm comfortable
doing it with automation.
You're right about the lack of filtering standards and I for one think
we should change that.
Jim
On Thu, 1 Feb 2001, Keith Moore wrote:
Date: Thu, 01 Feb 2001 16:08:08 -0500
From: Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu>
To: James M Galvin <galvin(_at_)acm(_dot_)org>
Cc: Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu>,
ietf(_at_)ietf(_dot_)org, midcom-admin(_at_)ietf(_dot_)org,
poised(_at_)lists(_dot_)tislabs(_dot_)com
Subject: Re: Mail sent to midcom (fwd)
> There's another subtlety here - lists that filter mail from
> non-subscribers penalize folks who use subaddressing for incoming
> list mail, since they don't post from the same address at which they
> are subscribed. Ideally, lists should not consider subaddresses
> when comparing a contributor's address against the list of
> subscribers. Failing that, it's helpful if a subscriber can get his
> "From" address registered as one for which there is special
> permission to post.
>
> Your suggestion to "not consider subaddresses" is impractical at best,
> and illegal regardless.
On the contrary, it's clearly practical as I have running code in
bulk_mailer that does this (which will be in the next release).
Nor is it illegal. Since there are no standards regarding list filtering,
there are no standards that prohibit lists from doing filtering using
fuzzy matching rather than exact matching on an address. My guess is that
most lists that filter on source address are already taking liberties
when comparing addresses - they're doing case-insensitive comparisons
of the local-part when according to the standards the local-part is
allowed to be case-sensitive.
It doesn't take rocket science for the list to seperately compare
the domain of an email address and the portions of the local-parts
up to but not including any of the separators commonly used:
( + - / . = # )
> hosting the elist. Even if it did you're suggesting the elist server
> should peek or otherwise parse the localpart of an non-local email
> address and that is wrong.
Guess we'd better put a stop to those case-insensitive comparisons, then.
> The only practical solution is, as you propose, that the elist needs to
> have a separate list of addresses approved to submit messages.
Actually I've demonstrated that there is another practical solution, one
which is unlikely to penalize those using subaddresses at all.
Keith