Jim Lyon
However, MARID's job is to verify the identity of the sender of a
message, and the sender isn't expressed anywhere except in the message
body. That's exactly why the PRA algorithm exists: to determine who
sent the message.
Yes. That's why I agree entirely with the proposed SUBMITTER extension.
Currently the MUA displays the FROM address to the end user as being the
originator of the email. Once the SUBMITTER extension is in use then the
MUA can do one of two things to stop phishing:-
1. Instead of displaying the FROM address as the originator it can
display the SUBMITTER address.
Or
2. Dump messages where FROM <> SUBMITTER.
There is little practical difference between these options although down
the track I would have a strong preference for option 1.
The MUA can not do real time SPF checking to stop spoofing; however we
happily leave that job to the MTA. We just ask the MUA to take care of
any content presentation problems (eg phishing) on its own.
SPF empowers the MTA to put a stop to spoofing.
SUBMITTER empowers the MUA to put a stop to phishing.
I am sure some proprietary MTA solutions are going to want to do this
MUA function for their mailbox users. That is fine. Plenty of notional
MTA like devices such as antivirus gateways and spam filters already
stick their nose into the email content. However that is a proprietary
"MTA+MUA gizmo" edge solution. There is no IETF standard that says an
MTA should look inside the message for spam or viruses. Just as there
should be no standard that tells the MTA to look inside the DATA section
of an email for delivery details.
Whether a device is an MTA or an MUA is up to the programmers. However
the standards should clearly delineate on MTA standard functions and MUA
standard functions.
As far as I am concerned comparing SUBMITTER and FROM is not a job for
the MTA. It's an MUA function.