On 5/14/2015 11:27 PM, Terry Zink wrote:
The Sender header field when present has been defined for decades
to represent the sending agent!
Maybe, maybe not.
Sorry, but there isn't much maybe about it.
The definition in the spec has been clear since the construct was
invented, in 1977.
On 5/15/15 8:52 AM, Dave Crocker wrote:
On 5/14/2015 11:27 PM, Terry Zink wrote:
The Sender header field when present has been defined for decades
to represent the sending agent!
Maybe, maybe not.
Sorry, but there isn't much maybe about it.
The definition in the spec has been clear
On Fri, May 15, 2015 at 8:52 AM, Dave Crocker d...@dcrocker.net wrote:
[*] In case folk miss the point, the Sender identifier is /always/
present, even when the Sender: field is not. If this isn't clear to
anyone, I encourage re-reading Section 3.4.2 of RFC 5322.
Did you mean 3.6.2?
-MSK
On 5/15/2015 12:35 PM, Murray S. Kucherawy wrote:
On Fri, May 15, 2015 at 8:52 AM, Dave Crocker d...@dcrocker.net
mailto:d...@dcrocker.net wrote:
[*] In case folk miss the point, the Sender identifier is /always/
present, even when the Sender: field is not. If this isn't clear to
On 5/15/2015 11:52 AM, Dave Crocker wrote:
But it is not an operationally practical choice. The problem is that
when that identifier is different from the content identifier, we have
the task of figuring out whether the identity in the Sender: field is
'authorized' to operate on behalf of the
