[Top] [All Lists]

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.