On Sat, May 10, 2003 at 02:15:38PM -0700, J C Lawrence wrote
On Sat, 10 May 2003 10:05:56 -0400
Paul Judge <paul(_dot_)judge(_at_)ciphertrust(_dot_)com> wrote:
Additionally, a proposal for a C/R protocol would be useful. This
would permit interaction between different C/R systems and allow
integration into MTAs and MUAs.
Given that the response portion and the transport used for the response
(email, web, phone, IM, XML/RPC, other) are unstandardisable, that only
leaves the challenge side.
Is there anything required by a challenge that's different from a
vacation bot?
Does anyone have a set of thoughts in either of these two directions
that they would like to put together and move forward?
For *JUST* C/R, the vacation bot spec seems sufficient. If you're
trying to glue C/R into another system, like a consent token system,
them I've already written a little on that aspect.
Probably raising my BI on this issue, but here goes...
1) I am *NOT* a fan of "C/R by default", but I believe that C/R does
have its place. Specifically, I use a variant of C/R as a safety net in
conjunction with aggressive blocking. This safety net has given me the
necessary confidence to start using SPEWS. I divide my email into 4
classes...
a) whitelist - a small subset of the net is unconditionally accepted
b) greylist - the vast majority of the net is accepted if it
doesn't flag out via DNSbls or local blocklist rules
c) blacklist - a small subset of the net is blocked via DNSbls and
other rules. As part of the 550 reject message, the
sender gets a URL on my personal website to a page
that lists the current temporary unfiltered email
address at which I may be contacted.
d) blacklist with extreme prejiduce - a small set of CIDRs from
which I do not want to hear. They do not get pointed
to my filter bypass page.
Current C/R systems challenge everybody except whitelisted
addresses. Given moderately aggressive filtering, I get hardly any spam
from the greylist, so I let it through.
2) In an effort to bypass spamblocks that check for invalid "From:"
domains, spammers now forge addresses from valid domains. Occasionally
the forged addresses are real, and an innocent 3rd-party gets deluged
with bounces. The default C/R method of sending a challenge email would
make this even worse. That's why I prefer making the challenge part of
an SMTP-stage reject.
--
Walter Dnes <waltdnes(_at_)waltdnes(_dot_)org>
Email users are divided into two classes;
1) Those who have effective spam-blocking
2) Those who wish they did
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg