Walt Dnes:
Checking my reject logs, I've noticed a new pattern the past couple of
weeks...
- *ONE* IP address
- sends 15 or 50 delivery attempts, approximately 1 attempt 2 every
seconds
- the envelope-sender is a legitimate looking address @gmail.com or
gmx.de or one of several .ru domains
I've noticed a similar pattern -- a large number of attempts from the
same bot to deliver mail to the same address, with the helo and rcpt
from strings varying. I have no idea what they are trying to do
because the retries are too close together to defeat greylisting [note
that greylisting states that one heuristic for changing state is that
the second e-mail arrive after a user-configured timeout]. Either the
command machine has broken logic, or the spammers are hoping the timeout
is set very low.
Daniel Feenberg:
Of these only 874 (13%) had an existing RDNS that did not reek of dynamic
assignment. That is, did not include the strings "dsl", "dynamic", "dial"
or "pool" and did not have any all-digit components.
I have one of the aforementioned addresses; my rDNS is
h-69-3-215-47.lsanca54.covad.net. Obviously, I would be averse to
having the rule you state run a widely used blocklist, but each of us
must run our installations as we see fit. If I see my address widely
blocked, I'd consider routing my mail through my ISP; the only reason I
don't is that I'm running sendmail, it's full featured, and I don't see
a good reason yet to take the extra hop via a remailer. My ability to
send you e-mail is a privilege, not a right, and you have the right to
deny me that privilege.
That said, such a rule tars the innocent along with the guilty. It's
like a google search that is over-broad. Think. We can do better.
I've been following the discussion about SPF, and here's what I noticed
in my particular case:
a) one of my domains is being used by spammers to generate fraudulent
rcpt from addresses. Hence, I get over 200 bounces per day to my
mailserver which commonly services 10 real messages (both inbound and
outbound) per day. I mentioned in a previous post that spam appliances
are also bouncing with "the spam you sent us was returned without
delivery" type messages.
b) two days ago, I added an SPF record to my DNS for the affected
domain. The SPF record verified correct via port25.com.
c) the average number of bounces has not decreased since I added the
SPF record. And the number of "the spam you sent us" messages from the
appliances has not decreased either.
The bad part about this is that aol is still among the bouncers, and
they are the ones hosting the spammer's portal pages!
My conclusion: most mailers, and, more sadly, most spam appliances, are
ignoring SPF. My own MTA (sendmail) has an SPF implementation available
as a milter (with a whole bunch of caveats that it not be used in a
production environment), and it is an option that does not ship with the
distro. Obviously SPF validation must be made part of the top MTA
distributions and enabled by default for it to have an effect. That
they have not is a sign that the MTA vendors don't think much of SPF,
or, for some reason, are not eager to embrace it.
I'm trying to figure out the politics of this.
Cheers,
Douglas Campbell
postmaster, craniumpro.com
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg