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