|
Re: Everyone Greylists Except Honeypots ... So Let's Not Spam Honeypots!
2007-12-11 13:36:53
On Dec 11, 2007, at 10:12 AM, David MacQuigg wrote:
At 12:34 AM 12/6/2007 -0800, Douglas Otis wrote:
For each direct source of spam, there are 4 sources of spam
emerging from tens of millions of MTAs as DSNs. The abuse of DSNs
is seriously eroding email's integrity.
"Bounce spam" is easy to block. Just don't accept a DSN for any
message you didn't send. This can be automated with an
authentication code in the return address on your outgoing mail.
This can only be done when the domain is able to impose a restriction
on permitted MSAs.
Few MTAs can operate and accept message for all recipients. The
inability for MTAs to handle all possible traffic exposes valid
recipients to being discovered.
Hiding valid email addresses is a fundamentally insoluble problem.
If legitimate senders can find out when an address is invalid (which
they must if we are to preserve reliability), then spammers can do
the same. Perhaps we can sacrifice some reliability for a little
more security, e.g. by sending "nosuch recipient" rejects only when
the sender is authenticated and reputable. The rest can be
tempfailed until they give up.
This is solvable. TBR can both limit discovery of valid email-
addresses AND greatly improve delivery integrity.
Providers of domain names, IP addresses, or certificates have a
conflict of interest, and are unable to prevent access to spammers.
Unwilling, not unable.
Unwilling, and likely unwise. There remains an inherent conflict of
interest. Using registration to limit access may also lead to forms
of extortion. What type of non-repudiation protects innocent
domains? Must all messages be signed by a CA? What limits the number
of certificates issued? Should all certificates be aged 30 days
before being accepted?
SMTP can not even mandate the use of an MX record to avoid
searching for policy records.
Reputation assessments of the last hop IP address is causing
spammers to merge their traffic with other domains. Often this
merging is accomplished through compromised residential systems.
The doubling rate is at six months, quickly making last hop
reputation assessments less meaningful.
I'm not seeing this at my receiver. I don't understand how it could
work. Please give more details on what you are seeing. e.g. How
are you doing the last-hop authentication?
Messages can be submitted as legitimate users, but likely originate
from compromised systems. Correlating source patterns and overall
volume determines the trend.
Network owners can block IP ranges assigned to residential
customers, either a port 25 block, or a policy published in DNS
(e.g. the Spamhaus Policy Block List). I guess this is another case
of unwilling, not unable.
Blocking port 25 is not a complete solution. Compromised systems can
bypass such blocks. In the case of compromised systems, abuse is
widely diffused such that rate limiting and outbound content filtering
offers diminished relief.
While DKIM attempts to provide essential transport information, it
is also prone to replay abuse and employs public key cryptography
where sign-once / send-many gives transmitters a resource advantage.
Grey-listing does not afford any long term strategy. However, the
use of temp errors can help avoid a complete denial of service as a
triage strategy for limited receiver resources. Reputation is then
used to establish priority. Processing undesired messages can
exceed 99% at very high volumes. This is not how the Internet
should work. A basic change to SMTP is needed to shift the burden
toward the transmitter.
I agree completely, except that I would not call simple extensions
"basic changes". The only thing I would change about SMTP, if I
could turn back the clock, would be to make the HELO name a
declaration of Identity, not a meaningless machine name.
Agreed, but then this also runs into conflicts of interest. An email-
provider often does not want credit. TBR demands an identity, a
matching MailFrom, and an MX record. In addition, TBR better
identifies a problem source, and not just the last MTA "holding the
bag" so to speak.
Greylisting increases the number of transactions per message, so
ultimately, this is headed in the wrong direction.
I think there is too much worry about these "extra transactions".
With a properly designed receiver, the number of transactions added
for greylisted or challenged messages should be very small compared
to the rest of the mailflow. Tempfails or challenges should go only
to the small percentage that is neither whitelisted nor clearly spam.
When spam must comply with grey-listing, transactions will
dramatically increase. The vast majority of email is spam where a
growing percentage can not be detected based upon content.
The TBR reference exchange can be done within a single transaction.
The transmitter is required to hold messages until the receiver is
ready. With a high level of source granularity, message
origination reputation should be able match the transmitter's level
of abuse and not breed super spam. References can be retained for
a period of time, where abuse pattern can be detected and used to
silently expunge abusive sources.
I like this proposal. Yet another tool for our arsenal. The weak
link is getting senders to implement it. If we expect senders to do
anything at all, it must be zero-cost and zero-risk.
The advantage afforded is prompt delivery. The alternative is Temp
fail, and then a subsequent retry. TBR avoids head of line blocking
that Temp fail will cause, and reduces recipient resources needed to
absorb all traffic, desired or not.
After discussing the TBR proposal in Vancouver, it appears several
changes are needed. These changes are aimed at supporting a queuing
architecture, instead of immediately supplanting a queue structure
with XAM. The requested changes are possible, although requires a
somewhat different command structure.
-Doug
|
|