How can IIS SMTP be forced to send delivery status notifications?
Peter Gibbons
how can I configure an IIS 6.0 SMTP to always send Delivery Status
Notifications (DSN) when they are requested even if the next server
offers DSN functionality in response to EHLO?
Kind regards,
Peter
Sanford Whiteman
> Notifications (DSN) when they are requested even if the next server
> offers DSN functionality in response to EHLO?
You seem to be looking for some kind of SMTP traceroute. I am not aware
of any way to produce this non-RFC behavior. Nor do I think it is a good
idea, since (a) it has major performance implication and (b) I don't see
what a regular user would make of DSNs from multiple hops, other than
confusion (though a technical user could deal with it appropriately).
Seems you could roll your own by writing a protocol event sink, or (in
batches) by tailing the logs and generating messages. What's the intended
application for this?
-- Sandy
------------------------------------
Sanford Whiteman, Chief Technologist
Broadleaf Systems, a division of
Cypress Integrated Systems, Inc.
------------------------------------
Grant Taylor
> how can I configure an IIS 6.0 SMTP to always send Delivery Status
> Notifications (DSN) when they are requested even if the next server
> offers DSN functionality in response to EHLO?
I do not believe there is an option in IIS (or any other MTA that I'm
aware of) to do this.
The closest thing that I can think of to do this is to have IIS use a
smart host that does not support (has it disabled) ESMTP. However this
will mean that no other servers down stream would see the DSN requests.
Grant. . . .
Sanford Whiteman
> smart host that does not support (has it disabled) ESMTP. However this
> will mean that no other servers down stream would see the DSN requests.
It's not just that no downstream servers would send DSNs with this setup
-- which indeed itself defeats the concept, as you say -- it's also that a
relayed DSN would _always_ be sent by the client, since the smart host
will always accept the message. It would be useless information. Might
as well not announce DSN at the zero-hop and just let the original client
take care of it in that case.
Better but still insufficient would be turning off _outbound_ ESMTP to the
remote domain and sending regular HELO. At least in this case the client
would be actually connecting to the remote MX and could determine whether
the message actually got relayed, delayed, or rejected.
But only a custom outbound event sink or batch job would truly fill the
bill.
Grant Taylor
> But only a custom outbound event sink or batch job would truly fill the
> bill.
I agree.
I was trying to think what the closest thing might be with in IIS SMTP
service.
Grant. . . .
Peter Gibbons
my problem is that most smtp systems my servers communicates with offer
the ESMPT DSN command but don't generate Delivery Status Notifications
if they are requested for it via the ESMPT DSN command by my servers.
My users then ask _me_ why they don't get DSN (relayed).
I did further research, too, and will test the following. It seems that
specific ESMTP verbs can be disabled:
http://support.microsoft.com/kb/262168
How to turn off 8BITMIME in Windows 2000 and in Windows Server 2003 SMTP
service
http://support.microsoft.com/kb/310155
HOW TO: Disable IIS 5.0 SMTP Service Socket Pooling in Windows 2000
http://support.microsoft.com/kb/257569 (How to turn off ESMTP verbs in
Exchange 2000 Server and in Exchange Server 2003)
Verbs Hexadecimal value Decimal value
DSN 0x40H 64
SmtpOutboundCommandSupportOptions Metabase Property (IIS 6.0)
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/1259016a-3450-45d7-9d61-53483798fa8c.mspx?mfr=true
SmtpInboundCommandSupportOptions Metabase Property (IIS 6.0)
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/fa9dd1ae-34dc-4f45-b32b-c20ba0ec0c48.mspx?mfr=true
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/1d1e5de4-fd63-40cd-bc5d-c20521548eed.mspx?mfr=true
Modify the IIS Metabase Directly (IIS 6.0)
So I should have to zero the 7th Least Significant Bit of metabase ID
36999 (SmtpOutboundCommandSupportOptions)? I also hope this property can
be used without MS Exchange.
- Peter
Sanford Whiteman
> the ESMPT DSN command but don't generate Delivery Status Notifications
> if they are requested for it via the ESMPT DSN command by my servers.
> My users then ask _me_ why they don't get DSN (relayed).
I'm trying to understand this. Your users have enough of a command of DSN
syntax to want DSNs... but not enough to understand (a) how DSN works by
RFC, nor (b) that DSN support is spotty and poorly implemented on other
servers? As you know, your server is under no obligation to send a DSN if
the remote server says it supports DSN. Nor should your server fail to
request a DSN as a client after claiming to be conforming as a server. So
you are doing all you can to be a proper, RFC-compliant citizen; you
shouldn't add to the breakage!
Though it would RFC-compliant, I don't understand how turning off your
users' ability to request a DSN completely (by turning off the verb)
solves their apparent desire to receive DSNs from the furthest hop
possible. That just ensures that DSNs don't work at all. But if they
need to be denied completely to learn a lesson, I guess it makes sense. :)
Grant Taylor
> Though it would RFC-compliant, I don't understand how turning off
> your users' ability to request a DSN completely (by turning off the
> verb) solves their apparent desire to receive DSNs from the furthest
> hop possible. That just ensures that DSNs don't work at all. But if
> they need to be denied completely to learn a lesson, I guess it makes
> sense. :)
The only reason that I can think of would be that clients would operate
differently if they could not request DSNs them selves. Thus the user
might know that no DSN is coming.
Another thought, though I'm not sure how to implement it in IIS, is to
configure things such that ESMTP is not used for known offending
receiving domains. That way the OP's server would return a "Gatewayed"
DSN while still allowing DSNs to work for other systems.
In the Sendmail world we configure the Mailertable to use the SMTP
mailer rather than the ESMTP mailer. That way, the server does not
attempt to use DSNs for the problematic receiving domains.
Grant. . . .
Sanford Whiteman
> differently if they could not request DSNs them selves. Thus the user
> might know that no DSN is coming.
You're right, but the submitting client would have to be very sensitive to
not just fall back silently. If it doesn't see 250-DSN support upon EHLO,
that's not necessarily a session-level error to fail (or even warn) on.
It'd basically have to force the error. I don't know how other MUAs
behave in this regard; I know mine (The Bat!) will happily submit a
message I've tagged as needing a DSN, regardless of real support at the
zero-hop. There's no error or warning in the logs.
> In the Sendmail world we configure the Mailertable to use the SMTP
> mailer rather than the ESMTP mailer. That way, the server does not
> attempt to use DSNs for the problematic receiving domains.
You can do the same for indiv remote domains in IIS. Turns off all ESMTP,
of course, and that removes certain other advantages (BDAT, SIZE, etc.).
It may or may not be worth it.
Grant Taylor
> You can do the same for indiv remote domains in IIS.
Is there another hidden Metabase option to do this for Remote domains?
If there is, it supersedes my last suggestion.
Grant. . . .
Grant Taylor
> Another thought, though I'm not sure how to implement it in IIS, is to
> configure things such that ESMTP is not used for known offending
> receiving domains.
Well after some quick Googling I think the only way that you can do what
I have suggested is to create a new SMTP Virtual Server (SVS) and
disable DSN and then configure your Default SVS to use it (the new SVS)
as the "smart host" for problematic "Remote" domain(s).
Here's how I did my test setup (combining Sandy's and my suggestions).
1) Create a new SVS and disable DSNs.
3) Reconfigure the new SVS to listen on a different port.
4) Configure a proxy port on a loop back address.
netsh interface portproxy add v4tov4 listenaddress=127.0.0.2
listenport=25 connectaddress=127.0.0.2 connectport=2525
5) Add a new "Remote" domain to your Default SVS for the problematic
receiving domain(s) that smart hosts through the new SVS.
Doing this will allow your users to continue using DSNs for domains that
support it -and- give you a way to provide a "Gatewayed" DSN for the
known domains that do not.
Grant. . . .
Sanford Whiteman
Not hidden, just the "Send HELO instead of EHLO" checkbox.
Grant Taylor
> Not hidden, just the "Send HELO instead of EHLO" checkbox.
*nod*
Missed that one.
Grant. . . .