-----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.
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.
[There's various timeout values involved w.r.t. minimum retry interval,
how long you remember a successful passthru etc.]
It never permanently rejects. The only notion of "incorrectly rejected"
there could be is if the implementation is broken and not implementing
greylisting. In which case, you're not testing greylisting, you're
testing something else.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows 2000)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQCVAwUBRDHTaJ3FmCyJjHfhAQKPgAP6A2VH7+za0kG16Ud/92Ue5Q/hwWZN7mYZ
5iPc8P0FAMSTpafl2sexhjl8VaNm3kT3yPJamSj5ubrE0rp0DqFXH4sRi/uLEdAu
SkdI57SgZZY/i7r1CeOlPG9fambi9J2Pz4hfVATkuXKbtmtsmUyDLv82s3PPN+MO
SHQWdAtqMtU=
=r4Yh
-----END PGP SIGNATURE-----
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg