Re: Why SRS really sucks

David Woodhouse <[email protected]> Mon, 03 Apr 2006 12:58:21 +0100
Newsgroups gmane.mail.spam.srs.general
Message-ID <[email protected]>
On Mon, 2006-04-03 at 04:05 -0700, william(at)elan.net wrote:
> > But mangling the recipient address unnecessarily would be bad -- there's
> > useful information in there which you'd be obscuring, so it's best to do
> > it only when you _need_ to.
> 
> What exactly is your point? Recipiet address exist solely for purposes
> of providing routing information on how to deliver the message. 

Sorry, I meant to say 'mangling the _sender_ address unnecessarily would
be bad'. 

It's true for the recipient address _too_, mind you -- as a general
principle, unnecessary mangling of _anything_ is bad, and loses
information.

> What different does it make if you see [email protected] or
> [email protected] as long as message will get to Tom (btw - we're
> talking about RCPT TO address not pretty visible address in To field
> that user will see).

(Still talking about the _recipient_ address, due to my mistake...)

I don't think anyone was really suggesting that we could mangle
recipient addresses and get away with it.

As an outsider, you _couldn't_ know that it would still get to Tom, if
you changed it to RCPT TO:<[email protected]>. In fact, it's a fairly
safe bet that it _wouldn't_ get to Tom.

Even if it _did_ get to one of his mailboxes, it still might not get
read -- it might be treated differently according to the address it was
delivered to. I certainly have filters such that mail will end up in a
different folder depending on the recipient address. Because my
cellphone isn't able to store its outgoing messages in an IMAP folder
but _is_ able to Bcc, there's one recipient address which will store the
mail in my outgoing folder, marked as already having been read. In that
case, I suppose that in one sense the message has 'got to me' because
it's in my mail store. But the chances of me reading it are slim.

Other people have catch-all aliases which collect mail to
[email protected] and dump it into a spamtrap mailbox. That wouldn't
be particularly useful either.


(Now, switching back to what I was _intending_ to say and answering the
equivalent question -- what difference does it make if you see
[email protected] or [email protected] in the _sender_ address? ...)

As I said, there's valid information in the reverse-path. It allows
sender verification callouts to work, so that you can refuse to accept
mail unless you know you can generate a bounce. If you trick the next
system into doing callouts back to your own mail server, instead of the
originating mail server, then you're bypassing that check. And you're
likely to end up with bounces to the SRS addresses which aren't actually
deliverable to the final destination, unless you've done callouts of
your own to verify the addresses.

It's also the most reliable way of filtering mailing lists...

Some people filter by looking at To: and Cc: headers. That gets false
positives when messages are cross-posted or Cc'd to you directly.
Instead of getting one copy in each list folder, or one in your inbox
and one in each list folder as appropriate, you'll end up with them all
in one folder. That may be a folder you never (or _rarely_ visit). 
It also gets false negatives when messages are Bcc'd to lists.

Some people filter by looking for List-Id: headers. That gets false
positives when someone sees a mail on a list they _know_ you aren't
actually paying any attention to right now, and redirects it to you with
all the headers intact. That happens to me a lot, and if I filtered on
List-Id: it would land in the list folder again and still be ignored --
instead of landing in my inbox where I see it.

The only reliable way of filtering mailing lists that I've found is to
filter on the reverse-path. If you get three copies of a mail -- one
from each of two lists and one direct, you get those three copies in the
appropriate folders because each arrives with a distinct reverse-path.

Some people don't like that outcome -- they _want_ to eliminate
duplicates. I could never find a suitable way to eliminate duplicates
while still having even vaguely predictable behaviour, so for me that
would be worse. 

It'd be quite nice if all three could be marked as 'read' when one of
them is, but that's getting off-topic...

-- 
dwmw2