On Apr 03 2006, Chris Lewis wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Laird Breyer wrote:
On Apr 03 2006, Seth Breidbart wrote:
Laird Breyer <laird(_at_)lbreyer(_dot_)com> wrote:
On Apr 03 2006, John Levine wrote:
Not really. I get spam complaints all the time for mail from lists
that I know perfectly well that they signed up for and confirmed.
"Oh, I don't want that any more." For the ones that aren't totally
redacted, my setup turns them into unsubs so they don't get any more
mail for that particular list, but I don't think it's fair to count
mail as spam if it depends on reading the recipient's mind in
real-time.
Isn't that perilously close to saying that if they decided something
in the past, they're not allowed to change their mind?
No. If someone asked for something, they're certainly entitled to
change their mind and request (and enforce) not getting it. They're
not entitled to change their mind and decide they never asked for it.
That's because you're using the "consent" version of the spam definition.
You're not using the "spam is what I don't want" definition. Reread
John's paragraph, he wrote "Oh, I don't want that any more".
I don't think John is calling that spam, is he? I don't either.
I won't block on that basis. I'll just help the user stop getting more.
He's not, neither are you. I'm using that definition, as do
other people who develop Bayesian content filters. John was giving an
example why he thinks that definition is unworkable. However, it gets
used every day by lots of people and filters. Seth mentioned deciding
they never asked for it.
Describe how you'd test greylisting without perturbing the system.
I already have outlined it several times now. The greylisting system
logs all the events which enter into the final decision. When a mail
is rejected, the record of evidence which triggered that rejection
(call it R) is kept.
Later, during QA, some volunteer users are sent a fraction of
rejection records R for mail messages that were intended for them, to
be approved. When the definition is "spam is what I say is spam",
these volunteers are the final arbiters of mail intended for them,
whether other people think they could do a better job or not.
Finally, you measure the number of records R which the volunteers say
are incorrectly rejected by the greylisting system.
Sorry, that notion is nonsensical with greylisting. Are you aware of
how greylisting works?
greylisting works by tempfailing the connection of _every_ "new" unique
sender/recipient/source IP triple (or some variant), then letting the
email through if the sending server retries. The notion being that most
spam senders cannot retry.
Yes, I am aware of that. I'm just trying (perhaps wrongly) to keep it
high level instead of discussing rejection modes at the SMTP
transaction level, or the socket connection level, etc. I think the
important aspect for testing is that the server doesn't always want to
relay the message body that the client wants to submit. So the mail is
effectively rejected. When (if) the client tries again, who's to say
that mail is the same one?
If you were developing a greylisting system and you were debugging it,
you'd log a lot of information. That's what I believe can be packaged
for QA testers in this scenario.
--
Laird Breyer.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg