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