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 usin
g
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

[ Post a follow-up to this message ]

> 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

[ Post a follow-up to this message ]

Should a /Drop folder be defined on a per-domain basis, as there are actuall
y
two domains, both with the same issue. In both cases, right
clicking/Properties on the domain name shows blank for the Drop directory, i
s
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
>

[ Post a follow-up to this message ]

> 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

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]

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 b
e
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 an
d
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
>

[ Post a follow-up to this message ]

> 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

[ Post a follow-up to this message ]