On Wed Terje wrote
In theory an MTA can server up web pages and wash laundry also.
However
it's
Dave wrote
You know what, MTA's today are good at is transmitting spam. Are you
suggesting they just stick to that or, do we make some changes.
# None of what I am saying is incompatible with stopping spam.
# I never said we should not make changes. Its just some changes are
# better than other changes. And why make changes that are not necessary
# and that break the layered transport model.
It's all very well to let the MUA block it but what if you get 100 spams
to
every real email.
That means your email costs just got multiplied by 100.
# If there is a SUBMITTER address and SPF records then the MTA can block
the email.
# If there is no SUBMITTER address or SPF records then the MUA is
smothered anyway.
Your are not solving the problem by using MUA filtering.
# You are if you also do MTA filtering based on SPF records and the
# SUBMITTER address. If there is no SUBMITTER address then nothing
changes.
And what do you do when the MUA blocks, you can't reject it's too late,
so
you're going to pester the poor sucker that got joe-jobbed for not
publishing spf records.
# No you don't pester anybody other than SUBMITTER. And if the MTA
accepted
# the SUBMITTER address as valid due to SPF checks then it is
appropriate to
# pester the SUBMITTER.
You need to change your thinking from "accept & bounce" to "reject"
# I never suggested that the message be bounced.
Rejecting can only be done by the MTA. Rejection puts the emphasis onto
the
sender to prove their authenticity.
# Yes but if both the SUBMITTER address and the MAIL FROM address passes
# authentication at the MTA level there is no reason to reject.
# The only thing for the MUA to do is to display SUBMITTER as the SENDER
# instead of displaying FROM as the SENDER.