On 8/27/20 6:07 AM, Victor Ivanov wrote:
I have been quietly following this discussion and I've seen SRS being
mentioned a number of times.
Welcome to an active part in the conversation. :-)
Now, I know what SRS _does_ (perhaps not fully?) to prevent unintended
rejection by a receiving MTA due to SPF policy and I know it's highly
recommended if not mandatory for any sensible MTA set-up (allegedly).
I don't think that SRS qualifies as recommended, much less mandatory.
More specifically, I think some of the email industry discourages it.
I know that Google wants people to not use SRS and instead would prefer
that people forward things without using SRS. I think that Google wants
to see the original SMTP envelope sender and make judgement calls on
that, even if doing so would violate the purported sending domain's SPF
records.
Note: SRS means that the domain that is used in the re-written sender
domain becomes associated with the content. So if you are forwarding
and re-writing bad content (virus, spam, or malware) your domain becomes
associated with said bad content.
Aside: One of the most important things when forwarding email is to
*ONLY* forward believed -> known to be clean and good email. Do *NOT*
forward spam, virus, malware, or otherwise questionable email.
I've heard / read about many people talking down / bad about SRS. But,
I personally have used SRS for 10-15 years and have not knowingly had
any ill side effects from doing so. I do conditionally apply SRS to
outgoing messages from domains that my server is not responsible for (MX
for inbound email).
However, I'm less aware of the actual use cases where it is absolutely
necessary to prevent above issues with SPF. Is SRS only relevant for
MTAs that do any sort of forwarding/open relay?
In short, "yes" and "correct".
You only /need/ (for however much value you give "need") SRS when you
are sending an email that would otherwise violate the SMTP envelope from
domain's SPF record. So you /might/ be able to conditionally apply SRS
to any outgoing email where there is an SPF policy that you would be
violating.
This is most likely going to happen when you are forwarding email. As
in someone has a .forward file.
I think that an open relay is a bad thing. Despite the fact that it
would benefit from things like SRS for the above mentioned reasons, I
think an open relay should be avoided. As such, I don't give it much
more thought.
Oddly enough, I find some of the explanations I came across (including
Wikipedia) fairly atrocious compared to SPF, DKIM, and DMARC which
are perfectly explained and their use-cases are very clear. Though
frankly, these three are fairly self explanatory themselves for anyone
with technical background.
I think there are those in the email industry that have an adverse
reaction to SPF in general and view SRS as a nasty hack (which might be
fair) that is only needed in response to SPF. They seem to really
dislike SPF and hate SRS.
I have been running my own MTA for just under a decade without SRS
(but with the rest of the above) and never had issues with delivery
- be that local or remote. However, I have explicitly disabled open
relay and do not make use of any forwarding maps.
That sounds reasonable. It also sounds like you have little to no need
for SRS.
I have a few friends that I forward email for. As such, I have need for
SRS.
It makes me wonder - am I missing something and have I just been lucky?
I don't think you're missing anything. Perhaps you have been lucky in
that your user base doesn't need forwarding. But that is perfectly fine
and perfectly legitimate use case.
--
Grant. . . .
unix || die
