On 17 Jan 2004 at 15:36, Phil Howard wrote:
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?
In the case of user mail sent directly that would be their local
mailbox address, with domain.
For forwarded mail it would be the local mailbox address. After all
that's the sender even though it's automated.
For a mailing list it's the mailing list address.
| 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:"?
Yes, it should be the "Sender:" since the forwarder is the sender. The
"From:" remains unchanged.
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?
Those addresses are passed untouched. We only deal with the "Sender:"
because we want to know who is the current sender on this mail server.
That should be an authenticated sender on the mail system sending the
message.
What about bounces that get sent to the envelope sender? Or is that not
allowed if an RFC822 Sender: header is present?
The bounce at the transaction phase would to the the "MAIL FROM:" since
that is where the message is coming from. Bounces later on would go as
required by the RFCs.
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?
That's a good question and I don't have a good answer but only my
opinion.
I think there should only be one "Sender:" in the header so either you
have to drop the older ones or change them in some way. Changing it to
"X-Sender:" and leaving them in their correct location compared with
the "Receive" headers is one way.
I think that this has already been addressed in RFC 2476.
----------------------------- RFC 2476 ------------------------------
8.1 Add 'Sender'
The MSA MAY add or replace the 'Sender' field, if the identity of the
sender is known and this is not given in the 'From' field.
The MSA MUST ensure that any address it places in a 'Sender' field is
in fact a valid mail address.
---------------------------------------------------------------------
So it's completely acceptable to replace the "Sender" field. I have
seen comments about this stating that renaming the previous sender to
"Old-Sender" could be a way to go but there is nothing said in the RFCs
on the issue. You could end up with several "Old-Sender"s.
If a mailing list follows this logic, what are the implications?
Glad you brought that up. Take a look at this mail list. The "Sender:
is the mail list address and the "From:" is the address of the original
sender. Now what does the "MAIL FROM: look like. Well here is the
transaction log from messages from this mailing list.
T 20040117 071528 3ff3d6ae Connection from 208.58.1.195
T 20040117 071528 3ff3d6ae EHLO portent.listbox.com
T 20040117 071529 3ff3d6ae MAIL
FROM:<owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
SIZE=11374
T 20040117 071530 3ff3d6ae RCPT TO:<john(_at_)themailstation(_dot_)net>
T 20040117 071531 3ff3d6ae DATA - 233 lines, 11372 bytes.
T 20040117 071531 3ff3d6ae QUIT
T 20040117 071531 3ff3d6ae Connection closed with 208.58.1.195, 3 sec.
elapsed.
As you can see the "MAIL FROM:" is the list owner which is as it should
be since that's where the message is being sent from.
| 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.
I agree that it's not the best place to abort but there are time when
the DATA phase does get aborted. Sending too much data is one place
I've seen mail system abort the DATA phase. In this case I see no
reason that it need be done.
The bottom line is that if you agree that the "MAIL FROM:" should
always be a valid sender on the mail system that the message is being
sent from, as it must from the reading of RFC 2476, then we need do
nothing to SPF other than point out what is valid to check and reject
on.
In this case what is being stated is that the "MAIL FROM:" e-mail
address should be an authenticated sender. If not and you have a "-all"
mail could be rejected.
Given that the next step would be to push the vendors to update their
mail system so that they always supply the senders valid authenticated
address in the "MAIL FROM:" and "Sender" records.
Now I can send my mail with my return address from any ISPs mail system
that I have authenticated access to which is as it should be.
--
-----------------------------------------------------------------------------
| 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;±¤Ö¤Íµø?¡
----------------------------------------------------------------------
John Warren
+--------------------------------------------------------------------+
| Any and all use of my email address for bulk email without my |
| expressed permission is prohibited. This means NO JUNK EMAIL, SPAM.|
| Support the anti-Spam amendment, Join at http://www.cauce.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;±¤Ö¤Íµø?¡