Invalid RCPT TO: list

Hi

We have the following set up for mail flow;

Application (Server1) > IIS SMTP relay server (Server2) > Sendmail
SMTP relay server (Server3)

We noticed that if the application tries to send to more than one
user, the mail is not delivered.
If the application tries to send to only one user, the mail is
delivered.

We checked the application log on Server1, and noticed the following;

MAIL FROM: Application@domain.co.uk
RCPT TO: <user1@domain.co.uk, user2@domain.co.uk, user3@domain.co.uk>

This is invalid and should be

RCPT TO: <user1@domain.co.uk>, <user2@domain.co.uk>,
<user3@domain.co.uk>

So far, so good....we know where the problem lies.

However, if I check the IIS log on Server2, I can see the following
entries;

EHLO - Server2 0 0 4 0 156 SMTP - - - -
2008-08-20 13:16:01 153.7.110.21 OutboundConnectionResponse
SMTPSVC1 Server2 - 25 -
- 250-Server3 0 0 19 0 313 SMTP - - -
-
2008-08-20 13:16:01 153.7.110.21 OutboundConnectionCommand SMTPSVC1
Server2 - 25
MAIL - FROM:<App@domain.co.uk>+SIZE=688 0 0 4 0
313 SMTP - - -
-
2008-08-20 13:16:01 153.7.110.21 OutboundConnectionResponse
SMTPSVC1 Server2 - 25 -
- 250+sender+<App@domain.co.uk>+OK 0 0 74 0 484
SMTP - - -
-
2008-08-20 13:16:01 153.7.110.21 OutboundConnectionCommand SMTPSVC1
Server2 - 25
RCPT - TO:<user1@domain.co.uk> 0 0 4 0 484 SMTP - - -
-
2008-08-20 13:16:01 153.7.110.21 OutboundConnectionCommand SMTPSVC1
Server2 - 25
RCPT - TO:<user2@domain.co.uk> 0 0 4 0 484 SMTP - - -
-
2008-08-20 13:16:01 153.7.110.21 OutboundConnectionCommand SMTPSVC1
Server2 - 25
RCPT - TO:<user3@domain.co.uk> 0 0 4 0 484 SMTP - - -
-
2008-08-20 13:16:01 153.7.110.21 OutboundConnectionResponse
SMTPSVC1 Server2 - 25 -
- 250+recipient+<user1@domain.co.uk>+OK 0 0 53 0 641 SMTP - - -
-
2008-08-20 13:16:03 153.7.110.21 OutboundConnectionResponse
SMTPSVC1 Server2 - 25 -
- 250+recipient+<user2@domain.co.uk>+OK 0 0 53 0 1016 SMTP - - -
-
2008-08-20 13:16:03 153.7.110.21 OutboundConnectionCommand SMTPSVC1
Server2 - 25
DATA - - 0 0 4 0 1016 SMTP - - -
-
2008-08-20 13:16:03 153.7.110.21 OutboundConnectionResponse
SMTPSVC1 Server2 - 25 -
- 354+Enter+mail,+end+with+"."+on+a+line+by+itself 0 0 48 0 1172
SMTP - - - -
2008-08-20 13:16:03 153.7.110.21 OutboundConnectionResponse
SMTPSVC1 Server2 - 25 -
- 250+Message+received+and+queued 0 0 31 0 1484 SMTP - - -
-
2008-08-20 13:16:03 153.7.110.21 OutboundConnectionCommand SMTPSVC1
Server2 - 25
QUIT - - 0 0 4 0 1484 SMTP - - - -

As you can see, the recipients are broken down into seperate user and
RCPT TO: addresses.

So, my question is -

a) If the application is sending out RCPT TO: <user1@domain.co.uk,
user2@domain.co.uk, user3@domain.co.uk>, why is IIS sending out (or
looks to me like it is) RCPT TO: user1@domain.co.uk, RCPT TO:
user2@domain.co.uk etc.

b) If IIS is sending RCPT TO: list as three users, what recipient list
does the MTA at Server3 see?

I would have thought the RCPT TO: list would stay the same as it
progressed through each MTA?

Hope someone can help!

> RCPT TO: <user1@domain.co.uk>, <user2@domain.co.uk>,
> <user3@domain.co.uk>

No, it *should* be:

RCPT TO: <user1@domain.co.uk>

RCPT TO: <user2@domain.co.uk>

RCPT TO: <user3@domain.co.uk>

> As you can see, the recipients are broken down into seperate user and
> RCPT TO: addresses.

....as is absolutely standard!

> a) If the application is sending out RCPT TO: <user1@domain.co.uk,
> user2@domain.co.uk, user3@domain.co.uk>, why is IIS sending out (or
> looks to me like it is) RCPT TO: user1@domain.co.uk, RCPT TO:
> user2@domain.co.uk etc.

The real question is what makes you believe that said mails are not
being delivered to the final recipient (which was your original
premise). What happens to those outbound connections? What does the
log show as the reason for final delivery failure?

> b) If IIS is sending RCPT TO: list as three users, what recipient list
> does the MTA at Server3 see?

It sees a list (usually an array) with three users.

But a "recipient list" is a logical concept that may be implemented in
any fashion by an MTA. It might well just be a text file with an
arbitrary number of lines. The important thing is the recipient list
be persistently linked with the original message headers/body, while
failed/successful delivery to each recipient is separately tracked.

> I would have thought the RCPT TO: list would stay the same as it
> progressed through each MTA?

Not necessarily -- an MTA may be forgiving and allow for non-standard
envelope information on the way in, but "massage" the envelope into
standard form on the way out.

Also, if an MTA knows a given RCPT is an alias for a "more true"
recipient or set of recipients, it is perfectly free to transform
and/or expand the recipient list before making the outbound
connection.

--Sandy


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

Thanks for your response....
>
> The *real *question *is what makes you believe that said mails are not
> being *delivered *to *the *final *recipient *(which *was your original
> premise). *What *happens *to those outbound connections? What does the
> log show as the reason for final delivery failure?

Server3 does not relay the messages to Exchange. The following error
message is given as a reason;

08-20-2008.13:03:26 sendmail-19261: Invalid address syntax
detected;
<user1@domain.co.uk, user2@domain.co.uk, user3@domain.co.uk>


> But a "recipient list" is a logical concept that may be implemented in
> any *fashion *by *an *MTA. *It *might well just be a text file with an
> arbitrary *number *of lines. The important thing is the recipient list
> be *persistently *linked with the original message headers/body, while
> failed/successful delivery to each recipient is separately tracked.

Ok, so are you saying that an MTA must not change the original header
information as a mail passes through it, even if it knows that it's
incorrect? For example, IIS must know that the original RCPT TO: is
invalid, that's why it changes it to three recipients on the way in,
however 'chooses' to change it back to the original RCTP TO: when it
connects to Server3 (as seen in the error message on Server3 I mention
above). Am I correct in thinking that MTA's must not change the RCPT
TO: information?

>
> > I would have thought the RCPT TO: list would stay the same as it
> > progressed through each MTA?
>
> Not *necessarily -- an MTA may be forgiving and allow for non-standard
> envelope *information *on *the way in, but "massage" the envelope into
> standard *form on the way out.
>
> Also, *if *an *MTA *knows *a *given RCPT is an alias for a "more true"
> recipient *or *set *of *recipients, *it is perfectly free to transform
> and/or * expand * the * recipient *list *before *making *the *outbound
> connection.

So, in that case, IIS *is* allowed to change the RCPT TO: to the
correct syntax?

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

Thanks for your response....


> The real question is what makes you believe that said mails are not
> being delivered to the final recipient (which was your original
> premise). What happens to those outbound connections? What does the
> log show as the reason for final delivery failure?



Server3 does not relay the messages to Exchange. The following error
message is given as a reason;

08-20-2008.13:03:26 sendmail-19261: Invalid address syntax
detected;
<us...@domain.co.uk, us...@domain.co.uk, us...@domain.co.uk>



> But a "recipient list" is a logical concept that may be implemented in
> any fashion by an MTA. It might well just be a text file with an
> arbitrary number of lines. The important thing is the recipient list
> be persistently linked with the original message headers/body, while
> failed/successful delivery to each recipient is separately tracked.


Ok, so are you saying that an MTA must not change the original header
information as a mail passes through it, even if it knows that it's
incorrect? For example, IIS must know that the original RCPT TO: is
invalid, that's why it changes it to three recipients on the way in,
however 'chooses' to change it back to the original RCTP TO: when it
connects to Server3 (as seen in the error message on Server3 I
mention
above). Am I correct in thinking that MTA's must not change the RCPT
TO: information?


> > I would have thought the RCPT TO: list would stay the same as it
> > progressed through each MTA?


> Not necessarily -- an MTA may be forgiving and allow for non-standard
> envelope information on the way in, but "massage" the envelope into
> standard form on the way out.


> Also, if an MTA knows a given RCPT is an alias for a "more true"
> recipient or set of recipients, it is perfectly free to transform
> and/or expand the recipient list before making the outbound
> connection.



So, in that case, IIS *is* allowed to change the RCPT TO: to the
correct syntax?

> Server3 does not relay the messages to Exchange. The following error
> message is given as a reason;
>
> 08-20-2008.13:03:26 sendmail-19261: Invalid address syntax
> detected;
> <user1@domain.co.uk, user2@domain.co.uk, user3@domain.co.uk>

This error message cannot be given in response to a properly
(re)formatted recipient list, so I think you are confusing two logs.

You said you saw outbound logs with correct RCPT TO commands; those
recipients are not going to *later* revert to their original, broken
formatting! It is possible that you are actually seeing this rejection
based on header (not envelope) formatting -- in other words, based on
message header/body content inspection by an anti-spam/anti-abuse
layer. While an MTA may fix up envelope commands, far rarer would be a
thorough fixup of internal content (which would in fact defeat many
methods of spam detection).

>> But a "recipient list" is a logical concept that may be implemented in
>> any *fashion *by *an *MTA. *It *might well just be a text file with an
>> arbitrary *number *of lines. The important thing is the recipient list
>> be *persistently *linked with the original message headers/body, while
>> failed/successful delivery to each recipient is separately tracked.
>
> Ok, so are you saying that an MTA must not change the original header
> information as a mail passes through it, even if it knows that it's
> incorrect?

No, quite the opposite (though you need to stop saying "header", since
we are talking about the SMTP envelope RCPT, not header/body data).

I am saying that an MTA may indeed "massage" misformatted inbound
commands if some kind of heuristics can be applied to come up with a
reasonable guess as to the submitter's intent.

For a common example, some MTAs may reject RCPTs with no angle
brackets; other MTAs will add the angle brackets after accepting the
message.

> For example, IIS must know that the original RCPT TO: is invalid,
> that's why it changes it to three recipients on the way in, however
> 'chooses' to change it back to the original RCTP TO: when it
> connects to Server3 (as seen in the error message on Server3 I
> mention above).

IIS cannot change the order or content of inbound commands.

It can readily change the content, extent etc. of outbound commands:
it can drop, add, or change recipient addresses, including recipient
domains. Nothing strange about that -- this kind of massaging may be
crucial to message delivery, for example from an MX to an internal
mailbox server farm.

> Am I correct in thinking that MTA's must not change the RCPT TO:
> information?

I would not say you are correct at all!

> So, in that case, IIS *is* allowed to change the RCPT TO: to the
> correct syntax?

Yes, it is allowed. But once the change is made, there will be no
record of the original broken syntax carried along with the message.
It is therefore impossible for the broken syntax to be reproduced
later.

--Sandy


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

On Aug 21, 10:04*pm, "Sanford Whiteman" <swhitemanlistens-
softw...@cypressintegrated.com> wrote:
> > Server3 does not relay the messages to Exchange. The following error
> > message is given as a reason;
>
> > * *08-20-2008.13:03:26 sendmail-19261: Invalid address syntax
> > detected;
> > * * * * *<us...@domain.co.uk, us...@domain.co.uk, us...@domain.co.uk>
>
> This *error *message *cannot *be *given *in *response *to*a *properly
> (re)formatted *recipient *list, so I think you are confusing two logs..
>
> You *said *you *saw outbound logs with correct RCPT TO commands; those
> recipients *are *not going to *later* revert to their original, broken
> formatting! It is possible that you are actually seeing this rejection
> based *on header (not envelope) formatting -- in other words, based on
> message *header/body *content *inspection *by *an anti-spam/anti-abuse
> layer. While an MTA may fix up envelope commands, far rarer would be a
> thorough *fixup *of *internal content (which would in fact defeat many
> methods of spam detection).

I don't have direct access to the Server3 box, but have set up a
'reply-to' set up for this application, and we have the following
NDR's in there;

Your message was not delivered to the following recipients:

--address suppressed--: 553 5.6.0 Message Header syntax
error

An error was detected in the header of your message.
It can not be delivered as indicated below.

Many times this is caused by an error in a recipient address or an
invalid address separator or an attachment that is not properly
encoded.
Please make the needed corrections and send your message again.
"Syntax error in route address in To header: <user1@domain.co.uk"

--address suppressed--: 553 5.6.0 Message Header syntax
error

An error was detected in the header of your message.
It can not be delivered as indicated below.

Many times this is caused by an error in a recipient address or an
invalid address separator or an attachment that is not properly
encoded.
Please make the needed corrections and send your message again.
"Syntax error in route address in To header: <user1@domain.co.uk"

There were two attachments, one of which showed the header info
(below);

Date: Thu, 21 Aug 2008 02:15:54 +0200
From: <application@domain.co.uk >
To: <user1@domain.co.uk,user2@domain.co.uk, user3@domain.co.uk>
Subject: TEST
Content-Type: text/html; charset=UTF-8
X-Priority: 3

And this attachment as well;

Reporting-MTA: dns;server3@domain.co.uk

Original-Recipient: user1@domain.co.uk
Final-Recipient: rfc822;--suppressed--:;
Action: failed
Status: 5.6.0

Original-Recipient: user2@domain.co.uk
Final-Recipient: rfc822;--suppressed--:;
Action: failed
Status: 5.6.0

Original-Recipient: user3@domain.co.uk
Final-Recipient: rfc822;--suppressed--:;
Action: failed
Status: 5.6.0

So, it looks like IIS is reformatting the RCPT TO: command but because
the original header information contains the invalid syntax, the mail
is being rejected
by the MTA at Server3?

Thanks again for your input.

> So, it looks like IIS is reformatting the RCPT TO: command but
> because the original header information contains the invalid syntax,
> the mail is being rejected by the MTA at Server3?

Yes, even if the SMTP envelope information is adjusted, misformatted
headers inside the message data portion would *not* usually be
adjusted. And if your receiving MTA is sensitive enough to flag mail
with any non-RFC headers -- a good anti-abuse practice -- then your
mail will still not get delivered.

--Sandy


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

> Yes, *even *if the SMTP envelope information is adjusted, misformatted
> headers *inside *the *message *data *portion *would **not* *usually be
> adjusted. *And *if your receiving MTA is sensitive enough to flag mail
> with *any *non-RFC *headers -- a good anti-abuse practice -- then your
> mail will still not get delivered.

Thanks...any my last question on this;

From my understanding SMTP envelope information is derived from the
header information, i.e. at the first MUA (Server1), the envelope
information would have come from
the (invalid) header information. The way I see it, IIS corrects the
envelope information but no change is made to the header, hence the
NDR.
Will/should MTA's also adjust the header information if changes are
made to the envelope?

Thanks again for your help...

> From my understanding SMTP envelope information is derived from the
> header information, i.e. at the first MUA (Server1),

Servers are not MUAs. The MUA in question would be your mail client,
such as a common "bidirectional" app (POP3/IMAP4/SMTP application like
Outlook/OE or a webmail front end), or a "unidirectional" app
(SMTP-only mailing list blaster).

> the envelope information would have come from the (invalid) header
> information.

I wouldn't say "come from" is accurate.

It's true that an MUA like Outlook presents you with header-type
fields like "To" and "From" (as opposed to RCPT TO and MAIL FROM), and
extrapolates envelope information from those Outlook fields when
submitting the the message. But the message is not fully-formed RFC
822 header/body until that point -- it is in an intermediate,
proprietary format until you actually send the message -- so I am
inclined to call those fields "Outlook message fields" and not "header
fields".

My point is clearer when it comes to special-purpose mail blaster
MUAs, which frequently let you enter separate header information and
envelope information before sending (so, for example, the SMTP MAIL
FROM can be tagged for bounce tracking, while the header From: appears
in more user-readable form).

> The way I see it, IIS corrects the envelope information but no
> change is made to the header, hence the NDR.

Yes. And acting on the header information as-is, rather than fixing it
up silently, has long been a spamfighting measure.

> Will/should MTA's also adjust the header information if changes are
> made to the envelope?

I must say that this is completely answered at the top of my last
post.

>> Yes, *even *if the SMTP envelope information is adjusted, misformatted
>> headers *inside *the *message *data *portion *would **not* *usually be
>> adjusted. *

--Sandy



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

All understood now.

Thanks for the excellent help, it is much appreciated

Dilan