North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

SMTP: run-to-completion, backscatter, et cetera (Re: Spam filteringbcps ...)

  • From: Edward B. DREGER
  • Date: Thu Apr 13 00:48:49 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

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.


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

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

Frankly, I'd go for pull-based response codes just to be rid of
backscatter.  The rest is gravy.

Everquick Internet -
A division of Brotsman & Dreger, Inc. -
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:
[email protected] -*- [email protected] -*- [email protected]
Sending mail to spambait addresses is a great way to get blocked.
Ditto for broken OOO autoresponders and foolish AV software backscatter.