Subject: RE: MTAs should focus on email TRANSPORT not email CONTENT

From: "Terje Petersen" <[email-masked]>
Date: Tue, 20 Jul 2004 12:24:19 +1000

> 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.

---

From: Roy Badami <[email-masked]>
Date: Tue, 20 Jul 2004 20:15:20 +0100

>>>>> "Terje" == Terje Petersen <[email-masked]> writes:

    Terje> 2. Dump messages where FROM <> SUBMITTER.

But an MTA can reject the message at the MTA level.  Quietly dumping
messages anywhere is a bad thing, and it violates the spirit of the
reliable mail delivery prinicple, even if perhaps not the letter.

	 -roy

---

From: John Levine <[email-masked]>
Date: 21 Jul 2004 03:10:40 -0000

>But an MTA can reject the message at the MTA level. 

Right -- the MTA can easily look at the header as it receives the
message data and reject the message at the end of the data if it fails
the test.

While I sympathize with the goal of separating function, it's been
apparent for a long time that you often need to combine the
implementation of multiple levels to get acceptable performance. If I
had to push all my MTA spam filtering into the MUA, the load on my
mail servers would go up an order of magnitude.  Even if it has to
read the whole message before rejecting it, MTA time rejection is a
lot cheaper than MUA rejection because it avoids the entire queue and
deliver process.

For that matter, since no spammer with a room temperature IQ will ever
send spam with a SUBMITTER that doesn't pass, we're going to have to
check SUBMITTER vs. From: on every message anyway, so we might as well
skip a lot of useless programming and just check the From: directly.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
http://www.taugh.com

---

From: "David Beveridge" <[email-masked]>
Date: Thu, 22 Jul 2004 10:04:58 +1000

On Tuesday Terje wrote

> 2. Dump messages where FROM <> SUBMITTER.

I would pefer that the MUA say

From SUBMITTER on behalf of FROM

And it should reply to FROM unless there is a "Reply-To:" Header.

dave.