|
Home > Archive > IIS and SMTP > August 2007 > Emails going missing with IIS SMTP service
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Emails going missing with IIS SMTP service
|
|
| julian 2007-08-11, 7:19 am |
| Setup is W2K3 SP1, IIS 6.0.
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
Julian
| |
| Sanford Whiteman 2007-08-11, 7:17 pm |
| > 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
| |
| julian 2007-08-11, 7:17 pm |
| 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
"Sanford Whiteman" wrote:
>
> 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
>
| |
| Sanford Whiteman 2007-08-11, 7:17 pm |
| > 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.
--Sandy
| |
| Sanford Whiteman 2007-08-11, 7:17 pm |
| 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
| |
| julian 2007-08-11, 7:17 pm |
| 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
"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
>
| |
| Sanford Whiteman 2007-08-13, 1:18 am |
| > 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.
> 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.
> 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).
--Sandy
|
|
|
|
|