On 18 Jan 2004 at 23:10, Alex van den Bogaerdt wrote:
On Sun, Jan 18, 2004 at 08:04:03AM -0800, John Warren wrote:
Solution:
The Sending MTA/MSA must make sure that the "MAIL FROM" in the SMTP
envelope MUST always contain the valid local authenticated e-mail
address of the of the sender no matter what the sender puts in the
"FROM" or "REPLY-TO" fields in the message header. Both RFC 2476 and
2821should be updated to require this since it's currently ambiguous.
The Sending MTA Should replace or add, as required, a "SENDER" field to
the message header, as stated in RFC 2476, that matched the "MAIL
FROM" used in the SMTP envelope.
Just to make sure I understand everything you say, and in the mean
time asking some questions. Is the following a correct interpretation
of your message, and can you answer the questions?
User <xyz(_at_)domain(_dot_)tld> is on the road. He want to send a message
to <abc(_at_)other(_dot_)tld>, and do so from ISP "isp.tld" as user
<pqr(_at_)isp(_dot_)tld>
From pqr(_at_)isp(_dot_)tld
Received-by ....
...etc...
From: "user" <xyz(_at_)domain(_dot_)tld>
To: "other" <abc(_at_)other(_dot_)tld>
Sender: "user" <pqr(_at_)isp(_dot_)tld>
...etc...
Bounces (if any) will go to pqr(_at_)isp(_dot_)tld and replies will go to
xyz(_at_)domain(_dot_)tld
Correct.
So far so good. Now, this user wants to be able to read his mail.
At domain.tld, there is a forward setup. "Other" is replying to
the message and will do so to <xyz(_at_)domain(_dot_)tld>. domain.tld is
accepting the message, the .forward is processed and mail is being
sent out again to <pqr(_at_)isp(_dot_)tld>.
This will look like:
From xyz(_at_)domain(_dot_)tld
I don't see why the above line was shown so I will ignore it.
Received-by ....
...etc...
From: "Other" <other(_at_)other(_dot_)tld>
To: "user" <xyz(_at_)domain(_dot_)tld>
Sender: "user" <xyz(_at_)domain(_dot_)tld>
...etc...
No it forwarded would be as follows:
Received-by ....
...etc...
From: "Other" <other(_at_)other(_dot_)tld>
To: "user" <xyz(_at_)domain(_dot_)tld>
Sender: "user" <xyz(_at_)domain(_dot_)tld>
Resent-from: <xyz(_at_)domain(_dot_)tld>
Resent-to: <pqr(_at_)isp(_dot_)tld>
...etc...
The "resent-xxx" would let the mail server know that it was a forward
if there is a bounce so you don't get into a mail loop. See RFC 821 and
2821 3.6.6. Resent fields.
Bounces, if any, will go to <xyz(_at_)domain(_dot_)tld> and not to
<other(_at_)other(_dot_)tld>
According to some, this is unacceptable.
Why is this unacceptable? The sender "other(_at_)other(_dot_)tld" had their
message delivered to the correct address. If the message fails to
forward I don't think that the bounce message has or needs to go back
to the original sender since the message is still in the mailbox and
can be picked up by the user at a later date.
Consider this:
mail from: <xyz(_at_)domain(_dot_)tld>
250 ...
rcpt to: <pqr(_at_)isp(_dot_)tld>
5xx mailbox full
Not to be picky but I think that mailbox full would be a 4XX to allow
for a retry. I do get the point though.
At this moment, I think the MTA at "domain.tld" could process the
bounce to <other(_at_)other(_dot_)tld> but this does currently not happen. It
will go to <xyz(_at_)domain(_dot_)tld> at the moment.
Which is fine although you want to keep it from getting into a mail
loop. See above.
Another possibility is that the bounce is not generated by "domain.tld"
but by "isp.tld" and the resulting mail will be introduced like this:
mail from: <>
rcpt to: <xyz(_at_)domain(_dot_)tld>
Again, the bounce will be delivered to "xyz", not "other". Even worse,
many users will forward this bounce again, in stead of storing it
locally (good enough) or, even better, letting <other(_at_)other(_dot_)tld>
know.
Again the "Resent-xxx" should keep us from getting into a mail loop.
IMHO "domain.tld" accepted responsability for the message and should
therefore accept responibility for informing <other(_at_)other(_dot_)tld>
about
any delivery problems.
And the message was delivered to the correct user. If that user
forwarded the message to another mail box and it fails I see no reason
that this be sent back to the original sender.
It may be possible no direct communication can or may occur between
"isp.tld" and "other.tld" (for instance: blacklisting) so sending
the bounce from "isp.tld" to "other.tld" (as currently would happen
without SPF) is bad in it self.
Which is another reason that the bounce go back to xyz(_at_)domain(_dot_)tld
and
not other.tld.
Last but not least, "other.tld" does not expect a bounce from "isp.tld"
thus the bounce may end up inbetween all other spam. Would the bounce
have been sent by "domain.tld", it has a bigger chance to survive.
I would agree if I accepted that the bounce go back to other.tld which
I don't.
How does your proposal handle bounces? Can you provide an example
which includes forwarding, via a blind gateway that accepts messages
without being able to check if it can be delivered?
I'm sorry I don't know what you mean by a "blind gateway". In the case
of a simple forward bounces go back to the forwarding e-mail address
and the "Resent-xxx" should take care of the mail loops.
I should point out here that RFC 821 allowed "Resend-" to be used for a
forward where 2821 does not. I don't understand why that was changed
since there was nothing put in to account for forwarding in 2821.
cheers,
Alex
--
begin sig
http://www.googlism.com/index.htm?ism=alex+van+den+bogaerdt&type=1
This message was produced without any <iframe tags
-------
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;±¤Ö¤Íµø?¡