"Peter J. Holzer" <hjp-asrg(_at_)hjp(_dot_)at> wrote:
a) size of the body
There is the SMTP SIZE extension (RFC 1870), which is in widespread use.
Arg. That's what I get for not reading ~3,5k RFC's.
If the size extension is made mandatory for clients, many MTAs will have
to be upgraded or replaced. This is not zero impact.
It's a one-time cost to upgrade their systems. They may get this
feature for free, as part of their normal upgrade process. We already
know that *any* changes to SMTP use, implementation, or deployment
already have costs. So I'm less concerned about the deployment costs,
as long as they're small.
Unlike other solutions which require ongoing maintenance and user
interaction (e.g. DK user key distribution), requiring publication of
sender policy is a process which is transparent to all participants
above the MTA level. And even the MTA administrators don't have to do
more than set policy, and then maintain it.
We already have a voluntary mechanism for the client to disclose
this information.
Which is currently unhelpful... because many "trusted" systems don't
use it. So the information it provides is unreliable, in that it
doesn't help distinguish bad systems from good ones.
As a general principle, most systems could handle spam if they
published a policy for accepting spam (# of messages, size, arrival
rate, bandwidth, etc.), and then the spammers *followed* that policy.
Right not, there's no way for the recipient to publish their policy,
and there are few ways for the originator to publish what they intend
to send.
There's the following draft which is interesting:
http://www.potaroo.net/ietf/ids/draft-shveidel-mediasize-04.txt
It's part of the "lemonade" group, and would appear to be relevant.
But the authors intention for it is to allow MTA's to better handle
multi-media mail, not to deal with spam.
Syntactical objections to it are at:
https://www1.ietf.org/mail-archive/working-groups/lemonade/current/msg00285.html
Alan DeKok.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg