spf-discuss
[Top] [All Lists]

RE: Ignoring rejected mail?

2004-12-07 18:18:41
-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com] On Behalf Of David 
Woodhouse
Sent: woensdag 8 december 2004 0:35
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: RE: [spf-discuss] Ignoring rejected mail?

On Tue, 2004-12-07 at 22:42 +0000, Mark wrote:

And, as I explained to David, if SES has to be done at each hop which
adds a header/text, then you're better off just doing a quick SRS
rewrite. David's argument has always been that SES 'survives' the
travel through multiple hops, and thus becomes a true end-to-end
verification system.

That's never been my argument; at least not in that context. It
survives multiple 'hops' where your definition of a 'hop' is going
from SMTP server to SMTP server with standard forwarding, with no
modifications.

And on that "with no modifications" presumption hinges SES altogether. :)
And there is no such thing as "standard" forwarding. Using a .forward file
says nothing about what an ISP chooses to add/change, in terms of
headers/body, by its outgoing mail servers. And before you say it, no, I
am not talking about their own Received: headers. :) Nor does it address
Milters like MIMEDefang, on their incoming mail servers, who replace
inline content with links, or MIME-reformat the message altogether, long
before it ever hits the .forward file! Sure, they could do the SES check
before that; but if they then have to redo a SES-signing themselves, then
it looks suspiciously like an SRS rewrite; except, of course, that the
latter
is faster. :)

Truth is, SES has of yet to deliver on a robust message-signing scheme in
which messages can survive such common handling. Others have tried before
you, with dismal to minimal success. Perhaps your energy is best spent
solving the existing SES problems than bashing SPF/SRS at every turn?

- Mark 
 
        System Administrator Asarian-host.org
 
---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx


<Prev in Thread] Current Thread [Next in Thread>