|
|
You're in the
iis smtp nntp
group:Emails going missing with IIS SMTP service
iis smtp nntp:
Emails without attachments are 'always' delivered to the user mailbox for pickup by POP3. With attachments, some are certainly delivered, however some are not, although I have the delivering mailserver logs showing acceptance, and matching IIS mail log entries confirming arrival. One 'captive' example being used for testing never arrives in the user mailbox, and consists of three small .pdf files, with a short message. I have searched the drive using explorer but cannot find where it has gone. It is not in the badmail queue, nor is any NDR created. Where should it go when it is first accepted by the machine? Any suggestions? Thanks in advance
Should a /Drop folder be defined on a per-domain basis, as there are actually
two domains, both with the same issue. In both cases, right clicking/Properties on the domain name shows blank for the Drop directory, is this wrong? Many thanks Julian [quoted text, click to view] "Sanford Whiteman" wrote:
> > Where should it go when it is first accepted by the machine? Any > > suggestions? > > There is effectively no other place you can isolate a message for local > delivery before it is moved into a /Drop folder (because the move from the > queue is instantaneous). > > So you will need to test around that. Send a message for non-local > delivery (i.e. relay) to a domain you make temporarily unreachable, so you > can see it in the queue; also send a message to the Default /Drop domain > to see if delivery patterns are any different from when you send to an > extended POP /Drop. > > --Sandy
As you may have guessed, I 'inherited' this setup.
Results on the 'default' domain (there actually was one, but it was only the machine name, not a fully qualified domain name) are that messages without attachments do get through to the drop directory, but those with attachments dont. I'm not sure that I can test using a non-available remote domain and find it in the queue, as the machine is not set up to handle outgoing mail at all. However, I have just discovered that a windows script (written by Alex Feinman) setting up catchall mailboxes is running and handling both real domains which are marked (custom), I'm not sure how this works, could this be the problem - is there any other way of handling erroneously addressed mail? If not I guess I'll try and persuade the users not to have a catchall box and disable it. Many thanks for your continued help Julian [quoted text, click to view] "Sanford Whiteman" wrote:
> P.S. I am dropping out of sight until this late evening EST, but post what > results you can from these two tests (@ Default domain to check the > standard \Drop; @ unavailable Remote domain to copy a queued message > intact) and I will respond later. > > --Sandy
[quoted text, click to view]
> Where should it go when it is first accepted by the machine? Any > suggestions? There is effectively no other place you can isolate a message for local delivery before it is moved into a /Drop folder (because the move from the queue is instantaneous). So you will need to test around that. Send a message for non-local delivery (i.e. relay) to a domain you make temporarily unreachable, so you can see it in the queue; also send a message to the Default /Drop domain to see if delivery patterns are any different from when you send to an extended POP /Drop.
[quoted text, click to view]
> Should a /Drop folder be defined on a per-domain basis, as there are > actually two domains, both with the same issue. In both cases, right > clicking/Properties on the domain name shows blank for the Drop > directory, is this wrong? POP3 domains are extended POP \Drops -- you don't see the actual path to the folder, because the delivery is handled by the POP3 event sink intead of by the core SMTP delivery service. The Default domain (you should be able to create one, if you don't already have it) uses the standard \Drop mechanism, and you will be able to see its drop folder path. Testing using messages addresses @ the Default domain therefore eliminates any POP3-specific behavior.
P.S. I am dropping out of sight until this late evening EST, but post what
results you can from these two tests (@ Default domain to check the standard \Drop; @ unavailable Remote domain to copy a queued message intact) and I will respond later.
[quoted text, click to view]
> Results on the 'default' domain (there actually was one, but it was > only the machine name, not a fully qualified domain name) are that > messages without attachments do get through to the drop directory, > but those with attachments dont. Are you sure you don't have any other 3rd-party event sinks processing mail besides Alex's catchall sink? Have you disabled the sink and retested yet? Also, can you please send me (off-list) the output of the command cscript smtpreg.vbs /enum In a vanilla installation, there simply is no other place for local mail to go other than to a drop folder (standard or extended POP drop) or back to the recipient with a DSN. OTOH, once there is any extra transport-level processing in place, obvs. anything can happen, including silent deletion. [quoted text, click to view] > > I'm not sure that I can test using a non-available remote domain and > find it in the queue, as the machine is not set up to handle > outgoing mail at all. That makes it even easier. If the machine can resolve MX records, but can't connect to them, then mail will build up in the queue. Alternately, you can create a new, dummy Remote Domain and hard-code it so that it has a smart host that has an unreachable IP. That'll also create a queue backlog for direct "snapshot" inspection of outbound mail. [quoted text, click to view] > However, I have just discovered that a windows script (written by > Alex Feinman) setting up catchall mailboxes is running and handling > both real domains which are marked (custom), I'm not sure how this > works, could this be the problem - is there any other way of > handling erroneously addressed mail? If not I guess I'll try and > persuade the users not to have a catchall box and disable it. While it's absolutely vital to know what else is running within IIS SMTP, since this makes yours far from a plain-vanilla setup, a properly written event sink should not make any changes whatsoever to messages for which it isn't designed. As Alex is an MVP, I have no reason to believe *this* sink has any problems. It is true that his event sink will touch all of your e-mail, so I'll see if anything jumps out at me. You can disable the catchall sink using unreg.cmd, which should be in the installation directory. I'd also mention that the very idea of a catchall script is outdated and rather nonsensical if you want to preserve your server's stability under load -- it *encourages* the very issue that sinks like 5xxSink are designed to combat (accepting mail to unknown recipients).
Don't see what you're looking for? Try a search.
|
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |