Re: Invalid RCPT TO: list

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@xxxxxxxxxxxx, user2@xxxxxxxxxxxx, user3@xxxxxxxxxxxx>

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.
------------------------------------
.

Relevant Pages

  • Re: TCPIP V5.4, SMTP & non-existant users
    ... > clean out the mail files every day or two (and I had to write a ... RCPT TO: antinode.orgsms@antinode.org ... Recipient OK ... Invalid names longer than 12 characters are OK. ...
    (comp.os.vms)
  • Re: [Full-disclosure] Re: User Enumeration Flaw
    ... Most MTAs implement tarpitting of some sort, to limit VRFY or RCPT commands from a perticular IP to a certian threshold, before they start slowing them down. ... There are also ways to silently drop a session for a recipient that isn't in an external database -- and while this breaks the RFC, ... Connection closed by foreign host. ... What would happen if Al-Qaeda could figure out that there was a president in the whitehouse? ...
    (Full-Disclosure)
  • Re: Invalid RCPT TO: list
    ... RCPT TO: ... being delivered to the final recipient (which was your original ... does the MTA at Server3 see? ... failed/successful delivery to each recipient is separately tracked. ...
    (microsoft.public.inetserver.iis.smtp_nntp)
  • Re: [Full-disclosure] What makes Yahoo! a good merger candidate?
    ... I'm doing them a favor by reporting but all I got is this lousy ... 501 Syntax error in parameters or arguments ... RCPT TO: ... 250 recipient ok ...
    (Full-Disclosure)
  • Re: how to do coding to check mail delivered or not
    ... Some protocols such as X400 try hard to give delivery notices, ... your UA, your MTA, possibly some intermediary MTA, the recipient MTA, ... the recipient UA, the recipient. ... If you still don't get any confirmation of an actual communication ...
    (comp.lang.ruby)
Quantcast