[89946] in North American Network Operators' Group
SMTP: run-to-completion, backscatter, et cetera (Re: Spam filtering
daemon@ATHENA.MIT.EDU (Edward B. DREGER)
Thu Apr 13 00:47:59 2006
Date: Thu, 13 Apr 2006 04:47:32 +0000 (GMT)
From: "Edward B. DREGER" <eddy+public+spam@noc.everquick.net>
To: nanog@merit.edu
In-Reply-To: <3637.71.109.216.128.1144893404.squirrel@71.109.216.128>
Errors-To: owner-nanog@merit.edu
ST> Date: Wed, 12 Apr 2006 18:56:44 -0700 (PDT)
ST> From: Steve Thomas
ST> If you accept the message, you can presumably deliver it. In this
Possibly. However, insufficient storage is not the only cause of 4xx
status.
ST> day and age, anyone accepting mail for a domain without first
ST> checking the RCPT TO - even (especially?) on a backup MX - should
ST> have their head examined.
Especially.
ST> IN the event that the RCPT TO is valid but the message truly can't
ST> be delivered for some other reason, you should bounce the message
ST> and fix the problem.
*Iff* the bounce can be sent to the correct location. That's a big
iff these days.
ST> My point was that when it comes to spam, it should either be rejected
ST> inline or delivered.
That's ideal. I can think of several realistic conditions where a
message could be queued but not validated until later. I'm simply
stating that { accepted | pending | refused } is a reasonable set of
responses. From an end-to-end perspective, SMTP transactions are
asynchronous and not guaranteed, anyway.
You're advocating run-to-completion. I'm suggesting an asynchronous
realtime system instead. Polls could be coalesced.
Note also the implications of polling for message status: Eliminate
bounces. Want to know if a message went through? Poll. Receive bounce
inline if appropriate. That seems better than the current push-based
crapshoot.
Want to confirm that a user has retrieved a message? Now possible at
the MX level. Want to confirm receipt by the server without divulging
if the user has retrieved the message? Return a status code indicating
such.
Frankly, I'd go for pull-based response codes just to be rid of
backscatter. The rest is gravy.
Eddy
--
Everquick Internet - http://www.everquick.net/
A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 785 865 5885 Lawrence and [inter]national
Phone: +1 316 794 8922 Wichita
________________________________________________________________________
DO NOT send mail to the following addresses:
davidc@brics.com -*- jfconmaapaq@intc.net -*- sam@everquick.net
Sending mail to spambait addresses is a great way to get blocked.
Ditto for broken OOO autoresponders and foolish AV software backscatter.
