Does IIS SMTP understand source routing

[dilan.we...@gmail.com]

Hi

I have an application server, ServerA, that sends email to an SMTP
relay server, ServerB, that runs Windows 2003 SP2.

ServerB runs IIS SMTP virtual server. This is configured to send mail
to another SMTP relay running Sendmail (it's a long story why we have
all these steps!)

The application on ServerA is using source routing to send email;

i.e. the RCTP TO is RCPT TO: us...@kam.co.uk@serverB.kam.co.uk

The reason we are using source routing on ServerA is because it is
running OpenVMS and the owner says there is no other way to specify an
SMTP server other than in the RCTP TO field.

I notice on the IIS SMTP log on ServerB that this RCTP TO is changed
to: user1%kam....@serverb.kam.co.uk

But I guess IIS doesn't know what to do with it then, since the
message is not delivered. I can't even see any attempts within the IIS
log to connect to the Sendmail relay when sending to this TO:
address.

Does anyone know why this is happening? Can IIS SMTP virtual server
not understand source routing?

Any help appreciated!!

Thanks

[Sanford Whiteman]

> The reason we are using source routing on ServerA is because it is
> running OpenVMS and the owner says there is no other way to specify an
> SMTP server other than in the RCTP TO field.

Does your OpenVMS server need to originate connections to a large
number of internal/external hosts? Or, more directly, does it
currently use DNS for any other functions but SMTP?

> I notice on the IIS SMTP log on ServerB that this RCTP TO is changed
> to: user1%kam....@serverb.kam.co.uk

This non-standard source routing expression (the percent hack) should
not be expected to be supported by a typical modern MTA. It's non-RFC
-- and even the *RFC* version of source-routing is deprecated!

Without any further customization, IIS SMTP reacts to a percent-hack
address as if the left-hand-side (to the left of the rightmost "@"
sign) is the mailbox, and the right-hand-side (to the right of the
rightmost "@" sign) is the destination domain. In other words, it does
not regard the address is requiring any further "componentization" or
truncation before attempting to forward the e-mail.

Though the "%" is non-standard source routing, IIS SMTP reacts, in
essence, to the source routing attempt as dictated in RFC 1123 5.2.6:
it accepts the RCPT just fine, but since "...it does not implement the
relay function, it SHOULD attempt to deliver the message directly to
the host to the right of the right-most "@" sign."

It is possible to write your own transport event sink (event sink =
the IIS SMTP API) that will perform address truncation/munging
in-between accepting the message and forwarding it on. Since your
messages are getting accepted into the queue -- and thus will fire
transport sinks -- you can also change the recipient addresses so that
<1&2@3> becomes <1@2>.

--Sandy

------------------------------------
Sanford Whiteman, Chief Technologist
Broadleaf Systems, a division of
Cypress Integrated Systems, Inc.
------------------------------------

[dilan.we...@gmail.com]

> Does  your  OpenVMS  server  need  to originate connections to a large
> number   of  internal/external  hosts?  Or,  more  directly,  does  it
> currently use DNS for any other functions but SMTP?

No, that's the thing...it only needs to originate a connection to one
SMTP relay host. I would have thought there is somewhere
to set this, however I'm not an expert on OpenVMS and the owner says
there isn't.

> > I notice on the IIS SMTP log on ServerB that this RCTP TO is changed

> > to: user1%kam.co...@serverb.kam.co.uk

>
> This  non-standard source routing expression (the percent hack) should
> not  be expected to be supported by a typical modern MTA. It's non-RFC
> -- and even the *RFC* version of source-routing is deprecated!
>
> Without  any  further customization, IIS SMTP reacts to a percent-hack
> address  as  if  the  left-hand-side (to the left of the rightmost "@"
> sign)  is  the  mailbox,  and the right-hand-side (to the right of the
> rightmost "@" sign) is the destination domain. In other words, it does
> not  regard the address is requiring any further "componentization" or
> truncation  before attempting to forward the e-mail.

So IIS SMTP on ServerB is basically trying to send the mail to
user1%kam....@serverb.kam.co.uk?
So, in effect, it is trying to send the mail to itself? Would this
explain the lack of outbound connection attempts to
the Sendmail relay which IIS is configured to use?

>
> Though  the  "%"  is  non-standard source routing, IIS SMTP reacts, in
> essence,  to the source routing attempt as dictated in RFC 1123 5.2.6:
> it accepts the RCPT just fine, but since "...it does not implement the
> relay  function,  it SHOULD attempt to deliver the message directly to
> the host to the right of the right-most "@" sign."

Where is the % added? At the IIS SMTP level? The reason I ask is
because the server
is sending out mail to us...@kam.co.uk@serverb.kam.co.uk - there is no
% character in
this RCPT TO address. Does IIS translate this attempt to a percent-
hack?

> It  is  possible  to write your own transport event sink (event sink =
> the  IIS  SMTP  API)  that  will  perform  address  truncation/munging
> in-between  accepting  the  message  and  forwarding it on. Since your
> messages  are  getting  accepted  into the queue -- and thus will fire
> transport sinks -- you can also change the recipient addresses so that
> <1&2@3> becomes <1@2>.

Thanks...and thanks for the full reply and explanation, I appreciate
it.

Dilan

[Sanford Whiteman]

>> Does  your  OpenVMS  server  need  to originate connections to a large
>> number   of  internal/external  hosts?  Or,  more  directly,  does  it
>> currently use DNS for any other functions but SMTP?
>
> No, that's the thing...it only needs to originate a connection to one
> SMTP relay host. I would have thought there is somewhere
> to set this, however I'm not an expert on OpenVMS and the owner says
> there isn't.

I was actually asking for another reason.

What you are really lacking -- what you are attempting to use source
routing to "fix" -- is the ability to set a smarthost in your OpenVMS
SMTP client. And in extreme circumstances where...

[1] you can't set a smarthost in your SMTP client

and

[2] you can't safely/reliably deliver messages directly to destination
MXs from your SMTP client

*but* either

[3a] your SMTP client can be set to use a DNS server that is different
from the OS-level DNS server

or

[3b] you have only the OS-level DNS server to tweak, but you have zero
need for DNS resolution for any other outbound connections from the
box

... then there is an old-school means of simulating a smarthost. You
can set up a fake root DNS server that wildcards all MX records (for
all domains) to the intended smarthost machine. Of course, it also
fakes control of all other DNS records as well. That's why that DNS
server can't be used for any other function but for forcing SMTP
routing -- but it does the trick. Such tactics are not for the faint
of heart nor for those who are unfamiliar with _why_ they work. But
the DNS server setup itself is actually quite straightforward with all
major DNS vendors.

> So IIS SMTP on ServerB is basically trying to send the mail to
> user1%kam....@serverb.kam.co.uk?

Right.

> So, in effect, it is trying to send the mail to itself? Would this
> explain the lack of outbound connection attempts to
> the Sendmail relay which IIS is configured to use?

Yes.

> Where is the % added? At the IIS SMTP level? The reason I ask is
> because the server
> is sending out mail to us...@kam.co.uk@serverb.kam.co.uk - there is no
> % character in
> this RCPT TO address. Does IIS translate this attempt to a percent-
> hack?

I believe you'll find on the wire that OpenVMS is changing to the
percent hack before connecting to IIS SMTP.

> Thanks...and thanks for the full reply and explanation, I appreciate
> it.

No problem.

[dilan.we...@gmail.com]

> ...  then  there is an old-school means of simulating a smarthost. You
> can  set  up a fake root DNS server that wildcards all MX records (for
> all  domains)  to  the  intended smarthost machine. Of course, it also
> fakes  control  of  all other DNS records as well. That's why that DNS
> server  can't  be  used  for  any  other function but for forcing SMTP
> routing  --  but it does the trick. Such tactics are not for the faint
> of  heart  nor  for those who are unfamiliar with _why_ they work. But
> the DNS server setup itself is actually quite straightforward with all
> major DNS vendors.

Makes sense, thanks...I'll look into this.

>
> I  believe  you'll  find  on  the wire that OpenVMS is changing to the
> percent hack before connecting to IIS SMTP.

Just one final question and I'll have everything clear in my head :)

So, you're saying that even though the server is being explictly
configured with the following line;

RCPT TO: us...@kam.co.uk@serverb.kam.co.uk

The OpenVMS operating system is (transparently) changing to the
percent hack before connecting
to IIS? Do you know why this would occur? Why not just connect to IIS
with the original RCPT TO command?

Thanks again

[Sanford Whiteman]

> The OpenVMS operating system is (transparently) changing to the
> percent hack before connecting
> to IIS? Do you know why this would occur? Why not just connect to IIS
> with the original RCPT TO command?

While neither 1@2@3 nor 1%2@3 are RFC-valid, the latter is a shorthand
supported that is by some number of vendors. The RFC-valid, yet even
more uncommon (these days) format is @3:1@2.

Note 1@2@3 (two '@' symbols) is completely invalid at the SMTP
protocol level, while 1%2@3 is at least a valid mailbox
specification... but, as you have learned, it should not be expected
that a given mail server vendor will consider the '%' character to
encode any extra-special information. In other words, it is perfectly
permissible for a message to 1%2@3 to be delivered to mailbox '1%2' on
server '3' (if such a mailbox exists or is created on-the-fly).

> Just one final question and I'll have everything clear in my head

It's okay if it takes a couple more. :)

[Sanford Whiteman]

> While neither 1@2@3 nor 1%2@3 are RFC-valid, the latter is a shorthand
> supported that is by some number of vendors.

Ugh: s/b 'that is supported'.

[dilan.we...@gmail.com]

> Ugh: s/b 'that is supported'.

No worries...thanks for the help, very much appreciated! :)