SMTP: run-to-completion, backscatter, et cetera (Re: Spam filtering bcps ...)
Edward B. DREGER
eddy+public+spam at noc.everquick.net
Thu Apr 13 04:47:32 UTC 2006
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 at brics.com -*- jfconmaapaq at intc.net -*- sam at everquick.net
Sending mail to spambait addresses is a great way to get blocked.
Ditto for broken OOO autoresponders and foolish AV software backscatter.
More information about the NANOG
mailing list