From line has ()

[James Gray]

On Fri, 17 Mar 2006 01:26 am, Jethro R Binks wrote:
> On Fri, 17 Mar 2006, James Gray wrote:
> > > > The way I read RFC822 (and 2822) is that if an MTA is going to reject
> > > > a message it should do so as early in the transaction as possible. 
> > > > It should never accept a message it will not deliver.  So, if
> > > > Exchange is dropping the message after the final "dot+<CR>" due to a
> > > > malformed or rejected address, it should have done it during the
> > > > "MAIL FROM:" or "RCPT TO:" stage.  IOW, I believe this violates the
> > > > RFC.  But hey, it's Micrsoft - since when to THEY care about
> > > > published standards?!?
> > >
> > > That's nonesense, and even if you believed it, it bears no relation to
> > > his original question.
> >
> > Erm, read RFC2821 specifically section 3.3.  (Paraphrasing) Messages
> > should be rejected as soon as possible.  However, I did misread to OP's
> > question, and I accept that this, and my earlier comments, have nothing
> > to do with their problem.
>
> You said "I believe this violates the RFC".

That comment was based on the (incorrect) interpretation of the OP's question 
- ie, the problem was in the envelope addresses.  After correcting myself, 
you want to beat me over the head with my first response?  Sigh - see below 
for my last comment.

> It doesn't.  The RFC advises that you SHOULD do something a particular way,
> but does not forbid you from doing it another way if you have strong reasons
> for doing so

<SARCASM>
Really?  I hadn't realised the RFC's WEREN'T ratified ISO/IETF/IEEE standards.  
Thanks for pointing that out.  BTW, did you know the sky is blue on a clear 
day?
</SARCASM>


> , as per  the terminology of section 2.3.  One of these strong reasons might 
> be that for logging and tracking purposes you want to record more
> information about the message content.  However the RFC does point out, late
> in that section, "Using a "550 mailbox not found" (or equivalent) reply code
> after the data are accepted makes it difficult or impossible for the client
> to determine which recipients failed."

Which is exactly the reason why most MTA's don't behave that way.

> Another strong reason would be if your site policy states that you may
> find some DATA content objectionable (including mangled header content)
> and reject on that basis:

Yep.  That's what I said.  If you want to reject a message based on the body 
content or (non-envelope) headers, you have to wait until after the DATA 
section is finished.

Just so you don't get confused (and start flaming me again): my initial 
response regarding Exchange's compliance with the RFC's was based on the 
incorrect assumption the error was in the envelope "MAIL FROM" but wasn't 
being rejected until after the DATA section.  As you have stated, whilst that 
behaviour is not "violating" the RFC per se (hard to violate something that 
isn't necessarily enforceable), it DOES make your MTA quite difficult to 
communicate with from a client's perspective.

Now before you throw my own contradiction back in my face: I used the term 
"violate" in my original to suggest "does not follow the accepted normal MTA 
behaviour as outlined in the RFC's".  You can't really (literally) "violate" 
ANY RFC as they are not ratified standards.  RFC's may form the basis for an 
ISO/IETF/IEEE standard, but the RFC itself is not enforceable.  Any admin 
knows that.

Having re-read the OP's question, the problem is in the value of the "From:" 
header, not the "MAIL FROM:" envelope address.  The "From:" header lives in 
the DATA section, so it's obvious that the MTA can't reject based on that 
header until AFTER the "<CRLF>.".

Cheers,

James
-- 
"Life sucks, but it's better than the alternative."
-- Peter da Silva
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.mailscanner.info/pipermail/mailscanner/attachments/20060317/307d33b9/attachment-0001.bin