Re: [dmarc-ietf] Header Rewriting

[Douglas Foster <[e-mail]>]

A previous attempt at this reply was sent prematurely.  Sorry about that.

I said:
Forwarding hides information that the email filter needs to make a correct
decision.   Header rewrite hides the problem, but does not solve it.   When
we get the automation right, predicting user behavior will not be necessary.

Laura replied:
You’re going to need to provide evidence this is the case.

Happy to explain, but I have been saying as much for some time.

My source filtering uses five parameters:   Source IP, Reverse DNS of the
Source, Helo name, SMTP address, and From Address.

Assuming that a forwarder adds no threat content, the need to evaluate the
actual source remains.    But this is difficult to do:

-- Forwarding hides the three elements of server identity behind the
forwarding server.
-- SMTP rewrite hides the source domain identity, such as the ESP which
sent the message.
-- From rewrite hides the asserted author identity.

We have hidden everything.   If the forwarder could be trusted to block all
spam, this might not be a concern.   But everybody assesses spam
differently and everybody misses some of it.   As a group, forwarding
services have an incentive to minimize false positives, so the likelihood
of spam getting through is high.   Mailing lists have different incentives,
and should be able to block spam reliably.   Whether they do so or not is
outside my experience.




>
>