Marc Perkel wrote:
Jim Maul wrote:
Kelson wrote:
Matt Kettler wrote:
That said, some folks still hate it because you're using some (very
little) of their CPU and network to handle your spam.
Also, a large number of verifications (say, because someone has been
sending lots of spam with forged headers) looks suspiciously like a
dictionary attack.
Exactly. In effect what sender verification does is cause your server
to perform the dictionary attack instead of the spammer.
Say im a spammer. I send messages to [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], etc and see which ones are accepted to gather valid
addresses.
With sender verfication, spammer now sends messages to
[EMAIL PROTECTED] with a return address of [EMAIL PROTECTED],
[EMAIL PROTECTED], etc. Your server does the sender check to see if
[EMAIL PROTECTED] exists. Your server is doing the work for the spammer
now and looks exactly like a dictionary attack. This could (and does)
very easily get you onto several blacklists.
Sender verification? Not for me, thanks.
Generally a dictionary attach uses randon to addresses, not from
addresses. Sender verification works on the from address.
Generally, yes. But that is not to say that it couldnt be done other
ways. What i described above is a perfectly valid way for this to
happen as well.
And if I
didn't use sender verification it scould result in a bounce message to
the address that I would have verified and the bounce message is a far
words problem than sender verification.
If you do *recipient* verification as opposed to sender, why would there
be any bounce message at all? reject unknown recipients at smtp time.
Wheres the problem? All sender verification seems to do at this point
is create load on your and other peoples servers, and provide a
mechanism for spammers to have you do their work for them. Add to that
the fact that the from is always almost forged and what good is it?
Hardly seems worth it to me.
-Jim
