Talk:Sender Rewriting Scheme

This is a good writeup on the problem and history, but it doesn't actually say what SRS is or what it does. --kjj

No information about Sender Rewriting Scheme. How does it process?

This is a fantastic history (of the problem).. but says nothing about what SRS actually does/is/was/should be. Suggest moving this article to a page title "Why SRS Became Necessary" or another similar history-based page rather than continuing to use this as the primary discussion of what SRS actually is! 82.152.0.81 02:06, 8 September 2007 (UTC) william

Actually IMO it isn't a good history because it gets bogged-down in a lot of irrelevant detail about how email worked a long time ago - long before SRS was invented. — Preceding unsigned comment added by 87.194.105.247 (talk) 12:12, 21 March 2013 (UTC)

What I found interesting is why the documents regarding SRS did not seem to consider the percent-hack for mail, nor why it should be rejected. Granted it is unsecured, unauthenticated, and easily abused (none of that having been written), but technically it works as a valid rewriting scheme that will pass SPF.

Example: sender@example.com relayed via example.net => sender%example.com@example.net.

Thus it will typically pass SPF checks on example.net when forwarded, and replies/DSNs are still possible and will eventually relay back to example.com through each forwarding system just as the proposed SRS addresses do. Agreed that this is easily forged too, but where's the discussion on this in any of the SRS papers?

As it turns out, I don't use either the percent-hack nor the SRS algorithms presented. As an alternative, I use a local database of time-expired hashes which record forwarded senders who were SPF validated (as "pass") to process any mail/DSNs coming back. These hashes are "plussed" values to a dedicated, fixed local-part. The local-part by itself (i.e. without a hashed value) is rejected as "user unknown" just like any unknown (or expired/purged) hash value. This means that the hash gives a human reader no clue as to the identity of the original sender - so spammers don't know who they're trying to spam. The expiration time I use is 7 days - about a day longer than the highest usual delivery expiration time in use. Note also that for forwarded mail from senders which do NOT use SPF, there is no envelope rewrite, while SRS blindly rewrites on all mail. (Note: It would be inappropriate to feed mail addressed to expired hashes to a spamtrap as they were valid addresses during their lifetime and could be again should a hashed value ever repeat.) 2001:470:D:468:4D38:4D80:C9B0:7B3C (talk) 01:26, 27 November 2013 (UTC)

Can someone explain:

• What does the recipient see (in their MTA) as the displayed address of the sender? (i.e. does the apparent sender's email address get rewritten)?
• If the recipient replies (a normal reply, not a reject) to the mail, does it go back directly to the original sender, or back via the SRS gateway?

Thanks 78.32.19.201 (talk) 10:48, 1 September 2022 (UTC)

White list -> allow list

I think it would be good to change the use of "white list" at the end of the "Historical Background" section to "allow list". Is this a technical term that should be retained as-is, or can it be changed? Matt-bacon-bcm (talk) 21:03, 22 October 2023 (UTC)