ST> Date: Wed, 12 Apr 2006 10:16:53 -0700 (PDT) ST> From: Steve Thomas
ST> RFC 2821? ST> ST> ...the protocol requires that a server accept responsibility ST> for either delivering a message or properly reporting the ST> failure to do so. How does one properly report delivery failure to a guerrilla spammer? ST> Unless you're the final recipient of the message, you have no business ST> deleting it. If you've accept a message, you should either deliver or ST> bounce it, per RFC requirements. "Please automatically delete anything that might be spam. They'll call me if it's important. I know I'll lose some mail, but that's okay." Throwing RFC 2821 at that user probably would not have made them happy. As for MUST bounce using return-path... perhaps you've never experienced blowback from a joe job. It can be unpleasant. RFCs are for maintaining interoperability. They are not infallible. When a system is clearly broken, it's time to examine alternatives -- not to say that the RFC was handed down from on high. Proposal: MXes can say "2xx message queued with ID blahblahblah". They also can return 4xx "try back later codes". Yes? How about some return code that says "poll by $deadline if you want to know whether message ID blahblahblah was accepted or rejected"? No need to retransmit the entire message, and the sender can learn whether the message was actually accepted. 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: [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.