On Sat, Jan 17, 2004 at 08:49:00AM -0800, John Warren wrote:
| I think the "MAIL FROM:" transaction field should contain the
| authenticated sender address not the field supplied by the user in the
| "From" header field. The "MAIL FROM:" would then be the same as the
| "Sender" header field.
|
| Who is the true sender of the message? It has to the the authenticated
| sender not the "From" sender which could be forged even if it is a
| legal forgery.
And "authenticated sender" means what? Would that be the address of the
local mailbox from which automated forwarding comes from?
| I don't remember every seeing the contents of the "MAIL FROM:"
| transaction header every being passed on in the delivered message in
| any field that a mail client would display. So it makes since that the
| "MAIL FROM:" should the the authenticated sender true e-mail address.
|
| This would solve the issue and not be a kludge like SRS plus it uses
| all standard fields.
I'll try to re-iterate one of the several ideas that popped into my head
based on what you said. I'll pick the one that makes the most sense and
seems the most plausible as what you meant and what might work.
When a forwarder gets email addressed to an automatic forwarding address,
it will take the envelope sender (e.g. MAIL FROM) address on the incoming
transaction, and append an appropriate RFC822 header. Do you mean that
it should be "Sender:"? Then it would replace the envelope sender with
one that is true and authenticated. But the question is, what? The
original envelope sender, and any from the RFC822 headers, could be
forged. But is that OK anyway?
What about bounces that get sent to the envelope sender? Or is that not
allowed if an RFC822 Sender: header is present?
If a Sender already exists, should it be retained? replaced? added to?
If replaced, should it be changed to X-Sender: and retain that to effect
an addition without duplication?
If a mailing list follows this logic, what are the implications?
| Oh one more point, you can abort during the "DATA" phase, you don't
| have to accept the entire message. But in this case that would not be
| required.
It is preferred to not engage the DATA phase if at all possible. Had
your proposal really meant that it was required, it surely would not
be accepted.
--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
-------
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;±¤Ö¤Íµø?¡