That is one that you should read all the way, Ed did a very good job with it. This thread went into my Craig folder.
--Kevinm KMAP-SR, M, WLKMMAS, UCC+WCA, And Beyond http://www.daughtry.ca/ For Graphics and WebDesign, GO here! -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Martin Blackstone Sent: Thursday, June 27, 2002 10:40 AM To: Exchange Discussions Subject: RE: Catch All... I got tired. What did it say? -----Original Message----- From: Kevin Miller [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 27, 2002 10:37 AM To: Exchange Discussions Subject: RE: Catch All... That last paragraph says it all, Thanks for the long winded reply!!!!!! --Kevinm KMAP-SR, M, WLKMMAS, UCC+WCA, And Beyond http://www.daughtry.ca/ For Graphics and WebDesign, GO here! -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Ed Crowley Sent: Thursday, June 27, 2002 10:30 AM To: Exchange Discussions Subject: RE: Catch All... I apologize to those of you who subscribe to Martin's E2K list. I am excerpting my long-winded post from that forum. If, as an administrator for a domain, I decide that address [EMAIL PROTECTED] is the intended recipient for all unresolved addreses in my domain, then it's the intended recipient. A domain's administrator decides which addresses go with which recipients. I don't see how determining that "all addresses other than those already assigned" are associated with a dustbin mailbox is any different than specifically applying all those addresses as aliases to it, except that the latter is impractical. RFC 822 states: ------------------------------ RCPT <SP> TO:<forward-path> <CRLF> This command gives a forward-path identifying one recipient. If accepted, the receiver-SMTP returns a 250 OK reply, and stores the forward-path. If the recipient is unknown the receiver-SMTP returns a 550 Failure reply. ------------------------------ The key is "the recipient is unknown". I do not believe that this prohibits an administrator from deciding that the set of all addresses other than those specifically assigned to recipients are "known" and go to the dustbin mailbox. A little farther down, RFC 822 shows: ------------------------------- Example of the SMTP Procedure This SMTP example shows mail sent by Smith at host Alpha.ARPA, to Jones, Green, and Brown at host Beta.ARPA. Here we assume that host Alpha contacts host Beta directly. S: MAIL FROM:<[EMAIL PROTECTED]> R: 250 OK S: RCPT TO:<[EMAIL PROTECTED]> R: 250 OK S: RCPT TO:<[EMAIL PROTECTED]> R: 550 No such user here S: RCPT TO:<[EMAIL PROTECTED]> R: 250 OK --------------------------------- Exchange doesn't do this. Exchange accepts the message and issues an NDR afterward. Now, is Exchange's RFC non-compliant (that's what we're arguing here, isn't it?) because Exchange doesn't acknowledge unknown recipients in this way? I think not because this is an "example" and is not explicitly called out as a requirement. But you really could argue this one either way depending on your interpretation of how strictly the RFC is to be followed. So let's move to RFC 2821, which obsoletes RFC 821. The language therein is a little different. --------------------------------- The first or only argument to this command includes a forward-path (normally a mailbox and domain, always surrounded by "<" and ">" brackets) identifying one recipient. If accepted, the SMTP server returns a 250 OK reply and stores the forward-path. If the recipient is known not to be a deliverable address, the SMTP server returns a 550 reply, typically with a string such as "no such user - " and the mailbox name (other circumstances and reply codes are possible). This step of the procedure can be repeated any number of times. ---------------------------------- The key phrase is "known not to be a deliverable address", language strengthens an administrator's claim that a dustbin mailbox could be a deliverable address for all otherwise undefined addresses. That is, all otherwise undefined addresses are deliverable to the dustbin mailbox object. Farther down in RFC 2821, is the following paragraph: ----------------------------------- However, in practice, some servers do not perform recipient verification until after the message text is received. These servers SHOULD treat a failure for one or more recipients as a "subsequent failure" and return a mail message as discussed in section 6. Using a "550 mailbox not found" (or equivalent) reply code after the data are accepted makes it difficult or impossible for the client to determine which recipients failed. ------------------------------------ Note the SHOULD in capital letters and boldface. Issuing an NDR for an "unknown" recipient is optional! The RFCs provide for the VRFY command, which allows a sending SMTP server to verify addresses without sending a message. Use of this command allows a Spammer to quickly run through a list of generated addresses to determine which are real and which are not. Exchange, wisely in my view, does not support VRFY. Is this a violation of the RFCs? No, because VRFY is not in the required minimum set of commands. The reality is that the original RFCs were written without the foresight of a world of Spam. The Internet RFCs exist to ensure interoperability. Accepting mail for unknown recipients and delivering it to a catch-all mailbox, or even a black hole, does not affect interoperability one whit. It is, unfortunately, a pretty much necessary guard against address harvesting. I reiterate that the Exchange team's interpretation of the 550 bounce requirement is unnecessarily narrow and broadening it to allow for a *@mydomain.com address would be a valuable addition in light of today's onslaught of Spam. If Microsoft wants to take over the datacenter, the Exchange team should recognize that little things like these are why shops keep Unix or Linux sendmail systems between Exchange and the Internet. Exchange should allow for things like catch-all mailboxes, customizable telnet banners, and customizable NDRs if they want to rid us of having to deal with Unix and Linux mail routers. Ed Crowley MCSE+Internet MVP kcCC+I Tech Consultant hp Services Protecting the world from PSTs and Bricked Backups! -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Randal, Phil Sent: Thursday, June 27, 2002 10:05 AM To: Exchange Discussions Subject: RE: Catch All... from rfc2821 "6.1 Reliable Delivery and Replies by Email When the receiver-SMTP accepts a piece of mail (by sending a "250 OK" message in response to DATA), it is accepting responsibility for delivering or relaying the message. It must take this responsibility seriously. It MUST NOT lose the message for frivolous reasons, such as because the host later crashes or because of a predictable resource shortage. If there is a delivery failure after acceptance of a message, the receiver-SMTP MUST formulate and mail a notification message. This notification MUST be sent using a null ("<>") reverse path in the envelope. The recipient of this notification MUST be the address from the envelope return path (or the Return-Path: line). However, if this address is null ("<>"), the receiver-SMTP MUST NOT send a notification." Phil --------------------------------------------- Phil Randal Network Engineer Herefordshire Council Hereford, UK > -----Original Message----- > From: Kevin Miller [mailto:[EMAIL PROTECTED]] > Sent: 27 June 2002 17:51 > To: Exchange Discussions > Subject: RE: Catch All... > > > http://searchwin2000.techtarget.com/ateQuestionNResponse/0,289 > 625,sid1_c > id468033_tax285117,00.html This one according to Scott. > > --Kevinm KMAP-SR, M, WLKMMAS, UCC+WCA, And Beyond > http://www.daughtry.ca/ For Graphics and WebDesign, GO here! > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On Behalf Of Ed Crowley > Sent: Thursday, June 27, 2002 9:37 AM > To: Exchange Discussions > Subject: RE: Catch All... > > > Please post the relevant section of the RFC that the request "breaks". > > Ed Crowley MCSE+Internet MVP kcCC+I > Tech Consultant > hp Services > Protecting the world from PSTs and Bricked Backups! > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On Behalf Of Kevin Miller > Sent: Thursday, June 27, 2002 8:27 AM > To: Exchange Discussions > Subject: RE: Catch All... > > > Yes you can but it breaks the RFCS. And why would you want to? Do > > Catchall mailbox event sink for Exchange2000: > http://support.microsoft.com/default.aspx?scid=kb;en-us;Q32402 1&SD=MSKB& --Kevinm KMAP-SR, M, WLKMMAS, UCC+WCA, And Beyond http://www.daughtry.ca/ For Graphics and WebDesign, GO here! -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Gary Duckman Sent: Wednesday, June 26, 2002 6:27 AM To: Exchange Discussions Subject: Catch All... Hi Guys, I have not been on the list for over a year so excuse me if I have missed the threads on this.... Can I re-route all inbound unknown recipient mail to a single mailbox in Exchange 2000? (I known how to do it in 5.5) At the moment it goes into the badmail directory. This is for people who mispell addresses etc. Cheers, Gary _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Archives: http://www.swynk.com/sitesearch/search.asp To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED] _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Archives: http://www.swynk.com/sitesearch/search.asp To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED] _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Archives: http://www.swynk.com/sitesearch/search.asp To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED] _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Archives: http://www.swynk.com/sitesearch/search.asp To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED] _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Archives: http://www.swynk.com/sitesearch/search.asp To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED] _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Archives: http://www.swynk.com/sitesearch/search.asp To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED] _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Archives: http://www.swynk.com/sitesearch/search.asp To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED] _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Archives: http://www.swynk.com/sitesearch/search.asp To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED] _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Archives: http://www.swynk.com/sitesearch/search.asp To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED]
