ietf-mxcomp
[Top] [All Lists]

Re: rejection after DATA

2004-06-24 22:37:27

This is what is so disturbing.  Why do I have to explain this?   Honestly, I
don't want to buck the system or rub or step on any toes.  For the most
part, I have put my trust in the what I thought ware thousands of man-years
in this working group, with the historistical perspective for mail designs
and the laws that evolved around them.  I tried to provide some input and
insight when I thought was appropriate but for the most part, I felt you
guys will do the "right thing"   Instead, I am either being told to shut up
privately or told I'm out of scope or simply completely ignored.

By law,  rejection is legally acceptable at the transport level and at the
posting level for online hosting systems.  Once mail is accepted either by
transport or by online posting, you MUST:

    - maintain the intent of the user
    - maintain integrity
    - take responsibility for delivery

When push comes to shove., that is the law molded by US ECPA and if you been
involved in the industry as long as I have to see how it all evolved,  you
would know all this.    I really didn't think I needed to remind anyone of
this.

So yes, as a response to DATA, it is legally acceptable.  But SPF/SENDERID
is being promoted to POST SMTP systems and that is where the problem many
lies.  If you redesign your MTA to do dynamic validation, you conform to the
laws.

See my comment to David Walls

----- Original Message ----- 
From: "Meng Weng Wong" <mengwong(_at_)dumbo(_dot_)pobox(_dot_)com>
To: "Hector Santos" <hsantos(_at_)santronics(_dot_)com>
Cc: "MARID" <ietf-mxcomp(_at_)imc(_dot_)org>
Sent: Friday, June 25, 2004 12:06 AM
Subject: rejection after DATA



On Thu, Jun 24, 2004 at 09:40:11PM -0400, Hector Santos wrote:
|
| I urge people to review at how this concept of requiring mail to be
accepted
| by SMTP for delayed rejection on unreliable concepts and then leave it
for
| Local Policies to decide.

Can you explain what you mean?  In my understanding of
SenderID, an MTA can perform 2822 checks, and if it wishes
to reject the message as a result of those checks, it can do
so after DATA, but before the end of the SMTP transaction.

That is to say,

        << 220 dumbo.pobox.com ESMTP Postfix
        >> EHLO dumbo.pobox.com
        << 250-dumbo.pobox.com
        << 250-PIPELINING
        << 250-SIZE 10240000
        << 250-VRFY
        << 250-ETRN
        << 250 8BITMIME
        >> MAIL FROM:<mengwong(_at_)vw(_dot_)mailzone(_dot_)com>
        << 250 Ok
        >> RCPT TO:<mengwong(_at_)dumbo(_dot_)pobox(_dot_)com>
        << 250 Ok
        >> DATA
        << 354 End data with <CR><LF>.<CR><LF>
        >> From: mengwong(_at_)vw(_dot_)mailzone(_dot_)com
        >> To: mengwong(_at_)dumbo(_dot_)pobox(_dot_)com
        >> Subject: recipient test
        >> Message-ID: 
<1088136255(_dot_)84763-testmx-mengwong(_at_)dumbo(_dot_)pobox(_dot_)com>
        >>
        >> test
        >> .
here -> << 250 Ok: queued as CEA0E51C
        >> QUIT
        << 221 Bye

So instead of saying 250 OK, it says 550 Sorry Checks Failed.

Silently discarding messages has always been something I've
tried strenuously to avoid.