----- Original Message -----
From: "John Warren" <John(_at_)wenet(_dot_)tustin(_dot_)ca(_dot_)us>
To: <spf-devel(_at_)v2(_dot_)listbox(_dot_)com>;
<spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Saturday, January 17, 2004 4:15 PM
Subject: [spf-discuss] Solving the Forwarding Problem for good!!!
Why is this turning out to be such a big problem when there is such a
simple solution to the problem? It's called the "Sender" field in the
header and it's been there since day one, RFC 821.
Forget SRS, it's not needed.
Forwarders should always add a "Sender" header record because the they are
sending the forwarded message.
Mailing lists should use the "Sender" since they are sending the
message...
MSA's should always add a "Sender" header when the "From" field is not the
same as the authenticated sender.
SPF tests should always use the "Sender" if there present, not the "From".
So the SPF check should work as follows.
If there is a "Sender" use it for checking and ignore the "From" else use
"From".
Problem solved, now I can use my AOL address when sending from another
ISP without having an issue with SPF. The "From" is not forged if the
"sender" is present.
So Meng, can you update the SPF docs to include this and then we can
put this one to bed and move on to other topics.
As Alain already pointed out to you:
The problem with this approach (and others approaches based on header
fields, rather than the envelope) is that it forces the MTA to
actually accept the message, before being able to reject it.
With SPF as it stands now, the mail transaction can already be aborted
before a single byte of message data is transferred.
Yes. After the DATA phase, the message can still be rejected (like an
anti-virus milter would do, for instance), but not DURING the data phase.
So, once you negotiated the start of the DATA phase, you will then have to
slurp in the entire message first, which is rather inefficient for SPF
checks.
Other approaches based on header fields, rather than the envelope, also
suffer from possible replay-attacks; so, a signing scheme of sorts would
have to accompany them. I suggest you browse the archives a bit, John;
because much has already been written on this.
Your post certainly radiates enthusiasm, John. :) But, the odd Eureka moment
notwithstanding, I think, in general, it is fair to subject ourselves to the
sanity check of realizing that if hundreds of people have been looking for a
solution for hundreds of hours, that any brilliant solution that pops up in
our head within seconds, has probably already long since been considered,
and discarded, or frowned upon, for reasons we may not have immediately
thought of.
P.S. I took "spf-devel" off the cc; it has no place there.
- Mark
System Administrator Asarian-host.org
---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.4.txt
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡