In communicator 4.7, the X-Sender header indicates whether the user has authenticated (via IMAP or POP) by appending (unauthenticated) if they have not. This functionality has proven extremely useful to us to provide some first-line spoof detection. Its not secure mail, but its a lot better than nothing...

hmm, would this help as part of our security review?

it may help with our security review as Lisa mentioned.....

mail triage marking nsbeta-

For X-Sender to be implemented, I need generic access to the authentication state of the IMsgIncomingServer (which bug 62640 describes, and its attached patch fixes)

The above patch does all of x-sender (except prompt the user to log into an incoming msg server when not already authenticated). It's behavior is this: 1. X-Sender stuff only happens if "mail.use_x_sender" is true. 2. It looks at the From address on the mail, and finds an incoming msg server with a) the same username and b) the same domain. So: justin@ukans.edu would cause it to look for a POP or IMAP connection to something like justin/mail.ukans.edu 3. If a POP or IMAP server is found that matches, it checks to make sure the user is authenticated. If so, it puts the address of the site it authenticated against in the x-sender header (ie. X-Sender: justin@mail.ukans.edu) 4. If it fails to find an appropriate incoming msg server, or if the user is not authenticated to an appropriate server, it puts the From address into the x-sender header with (Unauthenticated) at the end [ie. X-Sender: justin@mail.ukans.edu (Unauthenticated)] I still need to deal with the case where the user has not authenticated to a pop/imap server before sending an email. To do that, I a good way to force a synchronous authenticated, and the current protocol code doesn't seem to have anything suited for the task. For now, not being authenticated before sending a message will cause the message to be marked unauthenticated (so check your mail before sending any).

*** Bug 67779 has been marked as a duplicate of this bug. ***

Can somebody give me an update on this bug? Why have the patches not been included in the tree? We are very anxious to have this bug fixed.

You might wish to contact myself or Prabhat (pkeni@netscape.com) offline about this. I'm failing to picture how this provides the 4.x functionality which required (proprietary) Netscape server extensions. One obtains the X-Sender info via imap/pop protocol extensions. These in turn were designed to carry SMTP-AUTH information all the way through to the message store to the viewing client "out of band".

I don't understand what X-SENDER does, and it just gives back an error on my mailserver and others, as seen in bug 67963. I think we should take out the X-SENDER command until it's working properly. 12/1/2002 10:21:19 PM - ( 12) XSENDER 1 12/1/2002 10:21:19 PM - ( 12) -ERR Unknown command See also Bug 67963: Feb 6 14:12:52 zeus popper[8765]: erich.iseli at pop-zh-9-1-dialup- 28.freesurf.ch (194.230.192.28): -ERR Unknown command: "xsender".

I googled X-Sender, and results 1, 7, and 10 were about removing the X-Sender from Eudora. 2, 3, 4, and 5 where about other stuff; 6 and 8 information on the protocol, and 9 about the POP command. Judging that more results about its removal than its informational page, I feel we may want to WONTFIX this. Oh, and I doubt mscott knows this exists :-)