ietf-mxcomp
[Top] [All Lists]

MTAs should focus on email TRANSPORT not email CONTENT

2004-07-19 17:44:13

All,

I have tried to read all of the Marid discussions almost since inception but I 
have not contributed anything to date. I hope what I have to say is not a waste 
of time or merely repeating what has already been said, however it is a view 
that I hold quite strongly. 

I am a system administrator that supports email servers for multiple 
organisations. Mostly small businesses that want fairly automated low 
maintenance solutions. 

MTAs should focus on email transport. Many proprietary solutions have MTAs 
dipping inside the email content to perform various tests looking for spam or 
otherwise. Surfcontrol is the example that I am most familiar with. Antivirus 
solutions are another obvious example. This is all fine; however I do not 
believe that any of it should be a standard function of an MTA. An MTA is a 
"message TRANSFER agent". Its job should not necessitate reading the DATA 
content of email.

My view is that the MARID standard should proceed as follows:-

1. Use SPF classic to verify the MAIL FROM address. 
2. Use SUBMITTER as an alternative test point if the sending MTA supports it. 
Otherwise break forwarding after the flag date.

If SUBMITTER does not match the FROM address within the DATA section of an 
email then the email content can be considered to be malformed. However it 
should be up to the MUA to deal with this, not the MTA. 

This would mean that most email forgery could be cured by MTAs doing SPF 
checking. There would still be a phishing opportunity for spammers etc that 
could claim a false SUBMITTER address. However once this becomes the dominant 
loophole for spammers and viruses then MUA developers would have user pressure 
expecting a relevant patch to fix the loophole. The MUA is the correct place to 
fix this problem. 

Conceptually the postal worker should not be opening mail in order to make the 
delivery. The content should be private. Maybe even encrypted (if we want to). 
If the content is all in Latin the postal worker should not be concerned. Just 
as the postal worker should not need to look at mail content so the MTA should 
not be looking at the DATA section of email. 

A mismatch between the SUBMITTER address and the FROM address is a content 
problem not a transport problem. 

MTAs should deal with transport. 
MUAs should deal with content. 

Of course proprietary anti-spam gateways could still do non-standard MUA type 
testing. However they would remain proprietary. Just as looking for spam 
keywords in the content of the DATA section is totally proprietary MTA 
function. Would anybody wish to make the lists of keywords checked by anti-spam 
gateways a "standard" MTA job? I think not. 

Having the MTA dip inside the DATA section in order to complete its job breaks 
the layered approach to transport. Breaking the layering limits the future 
potential of SMTP. Layering should not be broken without good cause. 

MARID should separate what is transport and what is content. Separate what is 
an MTA job and what is an MUA job. Moving MUA functions into the MTA should be 
proprietary not standard.   

Regards,
TERJE PETERSEN
ExceLAN
Sydney - Australia