In that case, I really think the proposed protocol should have provisions
for the mailing-list corner case; otherwise, this corner case will become
the path of least resistance for spam to get through. Just as an electrical
current, spam will then follow this path - perhaps not immediately, but
eventually, when it is one of the last opportunities left open.
'A solution is only as strong as it's weakest link'
Radu.
PS. I had the pleasure to go through your C/R procedure, and I appreciate
the ease of use from my end. How many mailboxes does your software protect?
We are merely specifying a protocol. The actual implementation of that
protocol and the actions that are taken based upon specific
messages are
up to individuals.
The intent was to see if this protocol provided a comprehensive set of
messages for CRI.
Exactly. If the process of deleting such spam is not
automated, then the spam protection is not really protecting
anything, and in fact it makes the spam problem worse by
providing a mechanism of guaranteed delivery.
Is it not the consensus that spam should be prevented from
reaching the mailbox?
If a spammer included exempt headers then the process would not be
automated and the message would be subject to manual deletion. The
intent is that valid email would automatically be delivered and
anything else would do something else.
2. About the contents: If a spammer would add headers to his
message to make it look like a mailing list, this message
would then not be subject to the other provisions of the
draft? Is there a separate draft/RFC to deal with the mailing
list/CR combination, or do you intend to address this in some way?
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg