-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Frank Ellermann wrote:
> Mark wrote:
> > As parameter to the MAIL command?? We're not talking the SMTP verb
> > "AUTH" (RFC 2554) here.
>
> Right, I'm not sure about this, my CRAM-MD5 test (1) did not cover it, I
> also never tried to use another MAIL FROM with this account. They kept
> the concept in RFC 4954 (successor of 2554), so I guess it's no hopeless
> case.
http://tools.ietf.org/html/rfc4954#section-5 says:
| 5. The AUTH Parameter to the MAIL FROM command
|
| AUTH=mailbox
|
| Arguments:
| A <mailbox> (see Section 4.1.2 of [SMTP]) that is associated
| with the identity that submitted the message to the delivery
| system, or the two character sequence "<>" indicating such an
| identity is unknown or insufficiently authenticated. To comply
| with restrictions imposed on ESMTP parameters, the <mailbox> is
| encoded inside an xtext. The syntax of an xtext is described in
| Section 4 of [ESMTP-DSN].
|
| Note:
| For the purposes of this discussion, "authenticated identity"
| refers to the identity (if any) derived from the authorization
| identity of previous AUTH command, while the terms "authorized
| identity" and "supplied <mailbox>" refer to the sender identity
| that is being associated with a particular message. Note that
| one authenticated identity may be able to identify messages as
| being sent by any number of authorized identities within a
| single session. For example, this may be the case when an SMTP
| server (one authenticated identity) is processing its queue
| (many messages with distinct authorized identities).
|
| Discussion:
| The optional AUTH parameter to the MAIL FROM command allows
| cooperating agents in a trusted environment to communicate the
| authorization identity associated with individual messages.
|
| If the server trusts the authenticated identity of the client to
| assert that the message was originally submitted by the supplied
| <mailbox>, then the server SHOULD supply the same <mailbox> in
| an AUTH parameter when relaying the message to any other server
| which supports the AUTH extension.
|
| For this reason, servers that advertise support for this
| extension MUST support the AUTH parameter to the MAIL FROM
| command even when the client has not authenticated itself to the
| server.
|
| A MAIL FROM parameter of AUTH=<> indicates that the original
| submitter of the message is not known. The server MUST NOT
| treat the message as having been originally submitted by the
| authenticated identity that resulted from the AUTH command.
|
| [...]
Hmmmm.
So, could it be argued that forwarders could just authenticate to the
receiver (their customer!) using SMTP-AUTH when forwarding mail, no
sophisticated forwarder whitelisting required?
Could this be a concept that we can pitch as some kind of "Forwarding NG"?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHhPIdwL7PKlBZWjsRAhYZAJ4xMVqHGE4L1m1U/ilOHOGk9Eh1AwCg4dxB
sgZE/5vX5DfkvidOWXNPJC8=
=tSGU
-----END PGP SIGNATURE-----
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=83733691-8f31d5
Powered by Listbox: http://www.listbox.com
Hash: SHA1
Frank Ellermann wrote:
> Mark wrote:
> > As parameter to the MAIL command?? We're not talking the SMTP verb
> > "AUTH" (RFC 2554) here.
>
> Right, I'm not sure about this, my CRAM-MD5 test (1) did not cover it, I
> also never tried to use another MAIL FROM with this account. They kept
> the concept in RFC 4954 (successor of 2554), so I guess it's no hopeless
> case.
http://tools.ietf.org/html/rfc4954#section-5 says:
| 5. The AUTH Parameter to the MAIL FROM command
|
| AUTH=mailbox
|
| Arguments:
| A <mailbox> (see Section 4.1.2 of [SMTP]) that is associated
| with the identity that submitted the message to the delivery
| system, or the two character sequence "<>" indicating such an
| identity is unknown or insufficiently authenticated. To comply
| with restrictions imposed on ESMTP parameters, the <mailbox> is
| encoded inside an xtext. The syntax of an xtext is described in
| Section 4 of [ESMTP-DSN].
|
| Note:
| For the purposes of this discussion, "authenticated identity"
| refers to the identity (if any) derived from the authorization
| identity of previous AUTH command, while the terms "authorized
| identity" and "supplied <mailbox>" refer to the sender identity
| that is being associated with a particular message. Note that
| one authenticated identity may be able to identify messages as
| being sent by any number of authorized identities within a
| single session. For example, this may be the case when an SMTP
| server (one authenticated identity) is processing its queue
| (many messages with distinct authorized identities).
|
| Discussion:
| The optional AUTH parameter to the MAIL FROM command allows
| cooperating agents in a trusted environment to communicate the
| authorization identity associated with individual messages.
|
| If the server trusts the authenticated identity of the client to
| assert that the message was originally submitted by the supplied
| <mailbox>, then the server SHOULD supply the same <mailbox> in
| an AUTH parameter when relaying the message to any other server
| which supports the AUTH extension.
|
| For this reason, servers that advertise support for this
| extension MUST support the AUTH parameter to the MAIL FROM
| command even when the client has not authenticated itself to the
| server.
|
| A MAIL FROM parameter of AUTH=<> indicates that the original
| submitter of the message is not known. The server MUST NOT
| treat the message as having been originally submitted by the
| authenticated identity that resulted from the AUTH command.
|
| [...]
Hmmmm.
So, could it be argued that forwarders could just authenticate to the
receiver (their customer!) using SMTP-AUTH when forwarding mail, no
sophisticated forwarder whitelisting required?
Could this be a concept that we can pitch as some kind of "Forwarding NG"?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHhPIdwL7PKlBZWjsRAhYZAJ4xMVqHGE4L1m1U/ilOHOGk9Eh1AwCg4dxB
sgZE/5vX5DfkvidOWXNPJC8=
=tSGU
-----END PGP SIGNATURE-----
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=83733691-8f31d5
Powered by Listbox: http://www.listbox.com