Subject: Re: 5xx errors in general and MXs
From: Keith Moore <[email-masked]>
To: Markus Stumpf <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Fri, 23 Apr 2004 08:40:56 -0400
List-Id: <ietf-smtp.imc.org>

IMHO:

- 5xx in response to RCPT is a permanent failure.  The client SHOULD NOT
  try to deliver that message to that recipient via other MXes. 

- If a server wants to say "try another MX" in response to RCPT then it
  SHOULD respond with 4xx.  There's no guarantee that the client will 
  use a different MX on the next try, but a robust client will do so.

- Mail domains that implement rejection policies based on IP address or
  other criteria SHOULD implement them consistently across all incoming
  message paths.  (note that this doesn't necessarily mean that all 
  MXes should implement the same policy at the SMTP level; it means that
  a message that is rejected for policy reasons will be rejected at 
  some point in the signal path no matter which MX the client chooses)

- Servers SHOULD NOT trust third party blacklists when deciding whether 
  to reject messages.  They are notoriously unreliable.

Keith

> 
> On another list we have a - meanwhile rather emotional - discussion
> about aggressive delivery attempts.
> 
> The origin of the discussion and the aggressive delivery attempts are
> - large sites rejecting (valid, i.e. non spam) emails from certain IP
>   addresses based on policy decision, while they accept the same email
>   from other IP addresses without any problems (DUL lists like AOL
>   uses them for 5xx greetings or prodigy.net uses them to answer
>   RCPT TO with "550 5.0.0 Access denied")
> - some unclear wordings in RFC 2821 (and historic 974) about what a
>   delivery is and what a "successful" delivery is.
>   In particular does a "5xx" code as an answer to a RCPT TO qualify
>   for a "successful delivery" in terms of a "successful connection"
>   or is a "successful delivery" to be interpreted in terms of a
>   "successful transmission" (RFC974 makes some differences but is
>   unclear about details, just as RFC 2821 is).
> 
> This discussion led to a view topics, namely
> - how authoritative are answers from any MX server for a domain or
>   is the authority of the answer limited to that particular mailserver
> - is a 5xx code from one of the MXs of a domain to be treated as a
>   global permanent failure or is it valid (and backed by wording in
>   e.g. RFC974
>      "Implementors are encouraged to write mailers so that they
>       try the MXs in order until one of the MXs accepts the message,
>       or all the MXs have been tried."
>   if I get e.g. a "550 go away" as an answer to a RCPT TO command to simply
>   disconnect and try the next MX and if I am through with all of them
>   to inject the message at a smarthost (e.g. my ISPs mailserver).
> - how to interpret the 5xx code that e.g. AOL uses for a greeting if they
>   reject connections for policy reasons.
> 
> The originator of the aggressive delivery strategy argued
> - if you don't want me to use any other of your MX hosts in case of
>   a 5xx code then don't list them.
> - if you don't want me to annul the policies set for a specific MX
>   then take care that all of your MXs enforce the same policy
> - there is no clear way for a receiving MTA to tell the sending MTA about
>   its policies like "we don't accept email from your IP but probably
>   will if you use your ISPs mailserver".
> 
> Would it be desirable to have specific message codes signalling policies to
> sending MTAs?
> 
> Comments and clarifications highly welcome,
> 
> 	\Maex
> 
> -- 
> SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
> Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
> "The security, stability and reliability of a computer system is reciprocally
>  proportional to the amount of vacuity between the ears of the admin"
> 

-- 
Regime Change 2004 - better late than never. 

Date: Fri, 23 Apr 2004 04:11:58 +0200
From: Markus Stumpf <[email-masked]>
To: [email-masked]
Subject: 5xx errors in general and MXs
Organization: SpaceNet AG, Muenchen, Germany
Sender: [email-masked]

On another list we have a - meanwhile rather emotional - discussion
about aggressive delivery attempts.

The origin of the discussion and the aggressive delivery attempts are
- large sites rejecting (valid, i.e. non spam) emails from certain IP
  addresses based on policy decision, while they accept the same email
  from other IP addresses without any problems (DUL lists like AOL
  uses them for 5xx greetings or prodigy.net uses them to answer
  RCPT TO with "550 5.0.0 Access denied")
- some unclear wordings in RFC 2821 (and historic 974) about what a
  delivery is and what a "successful" delivery is.
  In particular does a "5xx" code as an answer to a RCPT TO qualify
  for a "successful delivery" in terms of a "successful connection"
  or is a "successful delivery" to be interpreted in terms of a
  "successful transmission" (RFC974 makes some differences but is
  unclear about details, just as RFC 2821 is).

This discussion led to a view topics, namely
- how authoritative are answers from any MX server for a domain or
  is the authority of the answer limited to that particular mailserver
- is a 5xx code from one of the MXs of a domain to be treated as a
  global permanent failure or is it valid (and backed by wording in
  e.g. RFC974
     "Implementors are encouraged to write mailers so that they
      try the MXs in order until one of the MXs accepts the message,
      or all the MXs have been tried."
  if I get e.g. a "550 go away" as an answer to a RCPT TO command to simply
  disconnect and try the next MX and if I am through with all of them
  to inject the message at a smarthost (e.g. my ISPs mailserver).
- how to interpret the 5xx code that e.g. AOL uses for a greeting if they
  reject connections for policy reasons.

The originator of the aggressive delivery strategy argued
- if you don't want me to use any other of your MX hosts in case of
  a 5xx code then don't list them.
- if you don't want me to annul the policies set for a specific MX
  then take care that all of your MXs enforce the same policy
- there is no clear way for a receiving MTA to tell the sending MTA about
  its policies like "we don't accept email from your IP but probably
  will if you use your ISPs mailserver".

Would it be desirable to have specific message codes signalling policies to
sending MTAs?

Comments and clarifications highly welcome,

	\Maex

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"

Date: Thu, 22 Apr 2004 08:49:29 -0400
From: John C Klensin <[email-masked]>
To: bz <[email-masked]>, [email-masked]
Subject: Re: collected comments on "When NOT to Bounce Email"
Sender: [email-masked]

--On Monday, 19 April, 2004 10:47 -0500 bz 
<[email-masked]> wrote:

>
> I am preparing to rewrite
> http://www.ietf.org/internet-drafts/draft-zinn-smtp-bounces-00
> .txt taking into account the comments that have been made and
> a discussion on a related topic that took place on usenet.
>
> If anyone has specific wording that they would like to suggest
> for use in draft-zinn-smtp-bounces-01.txt, please let me know
> what to say and where to say it.
>
> Pr�cis of comment received so far. Credits and context of
> comments are in the appended longer version of the text, after
> the first line of dashes.
>
> My responses to the points are marked **bz:.
>
> 1. Title may be too broad. It may have the effect of making it
> harder for your document to get approved.
>
> **bz:	I am open to suggestions. Unless a better title is
> suggested, I am  staying with the one I have now.

Try some variation on "Some exceptions to the SMTP requirement 
to bounce undelivered messages"

>...
>
> 5. This RFC won't address cases where viruses forge the bounce
> message. It seems like there are at least three separate
> problems: - virus filter writers are too eager to tout their
> products :) - bounces to spam and viruses are often useless
> and they clog up the mail system - some software does issue
> multiple messages in an error condition, which is especially
> bad if the recipients of those messages can be chosen by an
> attacker.
>
> **bz:	Agreed.

I recommend that you explicitly include identification of those 
three cases in the document and identify which ones this 
proposal addresses/solves.

>...
> 10. The RFCs should state that when it would be harmful to the
> network to propagate an email (because of a virus or trojan)
> *any* MTA may drop it and, in fact, shouldn't reject or bounce
> unless there is a reasonable expectation that the sending
> address is correct.
>
> However it should also be made clear that this is for network
> protection only and not for general email policing - the old
> distinction between "abuse of the net" and "abuse on the net".
> We don't want to encourage vigilantism or the equivalent of
> flame wars between MTAs.
>
> In fact perhaps the RFCs should consider viruses explicitly as
> a type of email whose handling is to be specified.
> Rejecting/bouncing a virus is just as bad as delivering it.
> Even if a bounce goes back correctly to its originating system
> it might re-infect a cleaned system or infect other systems
> there - there may be load balancing so that a different machine
> receives it.

For the reason the author identifies in the second paragraph, 
this is an extremely dangerous suggestion.  Many people (and 
even MTA operators) have a lot of trouble distinguishing between 
things they find distasteful and things that are clearly 
network-harmful or user-harmful.

>...
> 15. I agree that the RFCs need to be fixed, but not to open
> the gates to silent dumping.
>...
> In this case, a
> notification should be sent to an abuse address for the
> sending MTA and wait for the upstream to fix their problem.

We have _far_ too many worked examples of this -- automatic 
notification of "abuse addresses" is at least as bad as 
forwarding viruses.  People will get it wrong and multiple 
reports flooding those addresses can actually act as a DoS 
attack on the process of getting things tracked down and fixed. 
Similarly for several other "alert the upstream" comments -- 
that is exactly the disease you are trying to stamp out.

Just my thoughts...
    john

Posted-and-Mailed: no
Subject: collected comments on "When NOT to Bounce Email"
From: bz <[email-masked]>
Organization: LSU Chemistry Department
To: [email-masked]
Date: Mon, 19 Apr 2004 10:47:35 -0500
Sender: [email-masked]

I am preparing to rewrite 
http://www.ietf.org/internet-drafts/draft-zinn-smtp-bounces-00.txt
taking into account the comments that have been made and a discussion on a
related topic that took place on usenet. 

If anyone has specific wording that they would like to suggest for use in
draft-zinn-smtp-bounces-01.txt, please let me know what to say and where
to say it. 

Pr�cis of comment received so far. Credits and context of comments are in
the appended longer version of the text, after the first line of dashes. 

My responses to the points are marked **bz:. 

1. Title may be too broad. It may have the effect of making it harder for
your document to get approved. 

**bz:	I am open to suggestions. Unless a better title is suggested, I am 
staying with the one I have now. 

2. It's an exaggeration to say that use of a false return-path 'amplifies'
an attack, since the message is only bounced if it doesn't get to the
recipient. 

**bz:	A virus addressed to multiple addressees can produce multiple bounces 
at the inbox of the forged sender. 

3. Its not appropriate to recommend what future RFCs should do, since
conditions will probably change before we get around to revising those
RFCs. Something will be done about the lack of authentication in email. We
don't know what it is yet. But this document is probably a temporary fix
rather than something to carve in stone. 

**bz:	Agreed. This is a temporary fix. I should make that clear. 

4. Section 6 is cute, but I think it would be better to leave it out. In
the next revision, you might mark the section "NOTE IN DRAFT - not to be
included in the published RFC" - and that way people won't argue about it.
Heck, people might even ask you to include it in the final RFC - and it
might even be reasonable if given a bit more context. 

**bz:	Ok.

5. This RFC won't address cases where viruses forge the bounce message. It
seems like there are at least three separate problems: - virus filter
writers are too eager to tout their products :) - bounces to spam and
viruses are often useless and they clog up the mail system - some software
does issue multiple messages in an error condition, which is especially
bad if the recipients of those messages can be chosen by an attacker. 

**bz:	Agreed. 

6. RFC 2821 doesn't actually say that you MUST always deliver or bounce.
It says the message must not be lost for frivolous reasons. Note however
that SHOULD essentially means "you MUST do this unless you have a good
reason to not do this". If you reliably know that a message is a virus, or
that the return-path is forged, you have a good reason to not send a
non-delivery report. And that seems perfectly consistent with SHOULD. I
might say something like "these recommendations contradict those of RFC
2821 sections X, Y, and Z. this departure from the specification is
considered to be a temporarily measure until such time as improvements to
SMTP make it possible to authenticate the envelope return-path". 

**bz:	I need to make it clear that RFC 2821 implicitly allows but does not
explicitly allow silent dropping and suggest changes. 

7. I would like to see the language in the first paragraph of section 3
broadened a little bit to include more than just "messages generated by
viruses". Shouldn't this specification allow messages that are virus
*infected* to be silently dropped, even if the message isn't generated by
a virus? What about phishing attack messages and other types of fraudulent
mail? What about other messages whose content is unquestionably malicious
or deceitful? 

**bz:	I need to broaden the language. How broad should it go? 

8. I have real mixed feelings about such a do-not-bounce proposal. On one
hand, bounces being sent to innocent third parties are a very big problem,
as you correctly point out. On the other hand, I think the LMAP proposals
can greatly reduce that problem, and thus make a do-not-bounce proposal
close to irrelevant. 

>From the practical standpoint, most of these sites that are bouncing virus
warnings and email worms are using out of date software and are unlikely
to comply with the recommendations that you propose. It is my
understanding that all major anti-virus software already has terminated
sending email to probably forged envelope-from addresses in their most
recent software, and many have done so for years. 

A year ago or so ago, I would have agreed with your proposal. Today, I
mildly disagree with it because I think there are better solutions and
loosening the RFCs would simply be used as a big excuse to silently drop
email that does not have a bogus envelope-from. 

**bz:	I suspect that a year from now, the situation will not be greatly 
different from today. I think that being able to cite BCP xxxxx when 
telling some idiot of a sysop to PLEASE stop bouncing viruses may make a 
small but valuable difference. 

The following comments were collected from a usenet discussion on nanae
that touched on the topic of the I-D. 

9. I am of the impression that the spirit and intention of the RFC's is
well served by revising what we mean by "delivered" to allow the MTA
nearest the apparent final-destination MUA to signal OK receipt when that
is correct, and then to determine on its own what to do with the
message--to deliver it to the spool for the MUA, ... or drop it on the
floor. We need to more clearly define the boundary and demarcation of
responsibility to remove the apparent requirement that the MTA do the
impossible. 

10. The RFCs should state that when it would be harmful to the network to
propagate an email (because of a virus or trojan) *any* MTA may drop it
and, in fact, shouldn't reject or bounce unless there is a reasonable
expectation that the sending address is correct. 

However it should also be made clear that this is for network protection
only and not for general email policing - the old distinction between
"abuse of the net" and "abuse on the net". We don't want to encourage
vigilantism or the equivalent of flame wars between MTAs. 

In fact perhaps the RFCs should consider viruses explicitly as a type of
email whose handling is to be specified. Rejecting/bouncing a virus is
just as bad as delivering it. Even if a bounce goes back correctly to its
originating system it might re-infect a cleaned system or infect other
systems there - there may be load balancing so that a different machine
receives it. 

11. That invites endless wars on what is virus, what is Trojan, what is
worm, what is ${catchy-metaphor-du-jur}, what is feature, what is bug. 

At layers 1 and 2, I think the receiving agent has the right to drop stuff
that in its sole judgment it can not handle. That right needs to be
codified up the stack to the top (including layers 8 and 9). 

12. FYI Infectious code detected and dropped.

13. Quite - and why I said it needed to be fairly strictly spelt out that
we're talking only of emails that, if let through, have the ability to
propagate or subvert and cause damage to the net as a whole, not just
inconvenience to the recipient or his ISP. Action for the latter should be
left to them and the sender's ISP only. 

14. If the offered object is unsatisfactory as determined by the receiver
it should be dealt-with in the way that introduces the least amount of
harm as determined by the agent at risk. 

15. I agree that the RFCs need to be fixed, but not to open the gates to
silent dumping. 

Instead, the RFCs should specify that DSNs must carry a reference to the
original message so that it can be possible to determine whether a DSN is
the result of a forgery before delivering the DSN to the purported sender. 

In the case where the MTA is certain that the sender address was forged,
as with a known virus or clearly identified spam, it is inappropriate to
either forward the mail to the recipient or bounce it back to the sender.
In this case, a notification should be sent to an abuse address for the
sending MTA and wait for the upstream to fix their problem. 

It is my opinion that all further communications from an MTA that forwards
viruses should be temporarily blocked until it is apparent that the
problem has been resolved. 

16. Let me grant for the sake of argument that a message MUST NEVER be
silently dropped. 

Now we have some implementation issues to work on. What shall I do if the
100 terabyte message comes in and I have no machine big enough to deal
with it, even to hold onto the stuff necessary to compose and  transmit a
minimal DSN. Silly you say? OK, maybe it is. 

 Suppose the message to be disposed of has headers that are known to me be
 bogus except for the stuff my machine inserted. To whom should I send the
 DSN? 

 Suppose the message to be disposed of has headers that are bogus except
 for the stuff my machine inserted, but I don't know that. To whom should
 I send the DSN? 

17. This could depend on how you know the headers are bogus. If the
message fits a known spam profile that should have been caught upstream
you should lart the upstream source for dumping this on you. 

If you don't know for sure, you should follow the RFC and send a simple
DSN to the envelope sender with a reference to the Message ID of the
dropped message. If all DSNs contained a standard header that referenced
the Message ID of the original message it would be no problem for the
users ISP or MUA to arrange to filter out any DSNs for messages the user
did not originate. This would solve the problem of users receiving bogus
DSNs without disrupting the benefit of valid DSNs. 

18. I don't want ANY more DSN's for messages I know nothing about.

19. RFCs have a long record of not keeping up with things like spam.

I wouldn't worry about violating the letter of the law if there is a good
reason, especially if you are being nice to the rest of the net rather
than being selfish. 

20. Make it simple. Screw the RFCs - if he doesn't want all viruses that
come *from* his MTA returned to *his* mailbox, he had better stop sending
them to *your* MTA. 

21. There is no compulsion to accept. However it is considering a serious
abuse for an intermediate MTA to accept an email and not to offer it on.
And if that offer is rejected, RFCs require a bounce to be generated and
sent back. 

The point is that in the current climate there are times when the correct
disposition *is* to accept and drop. 

22. Exactly so. With no forbidding rights accruing to the sender, I would
clarify that the "Intermediate MTA", if operated by or on behalf of the
addressee, is under no obligation to do anything in particular with
respect to the sender. 

Send me paper mail I don't want and I (or my agent) will put it in the
appropriate bin (here labeled "Firewood") straight away. 

23. BZZZT! "Wrong" problem. Either the 'sending' (i.e. 'SMTP client')
system _knows_ who the *actual* sender is, and can direct the message
_there_, regardless of the 'putative sender' in the "From: " line, or
they've got no business running a mail-server. If they 'relay' for other
servers, then they should insist that those servers that they relay _for_
do *not* send 'misidentified source' mail to them for relay. 

The 'permanent' fix for this problem it to check _outgoing_ mail, and
verify that the 'from' (envelope _and_ "from: " line) addresses have been
'registered' by the user that is actually sending the mail. ('registering'
means simply 'telling' the mail-server operator that you'll be using that
'from' address. _Ideally_, they'd send a confirmation request _to_ that
address, and not let it pass until an ACK is received -- that however, is
probably _gross_ overkill, and generally un-necessary) 

24. When it's known to be a virus/trojan/worm, don't send a notification
to the supposed sender. Otherwise, do. 

25. Last fall, I had a domain forged by a spammer who was hitting AOL.
After about 1000 bounces, I called AOL to ask if they could do something
about the flow coming from their servers. I received nothing but an
attitude from their email support crew. My workaround was to write a
script that discards AOL bounces sent to unused email addresses. An
interesting note is there were no bounces from any host other than AOL. 

Back to the virus "bounce" ... I have received virus warnings from hosts
that not only sent a warning to the forged email address but returned the
virus as an attachment! One might say that an unsecured Microsoft box
effectively turned a Linux box into a virus distribution center.
Cooperative computing! 

26. So this is a case where refusing is the *worse* option. If one's
already received the email, which one must have to have identified a
virus, then just drop it. Refusing, and so causing the sending MTA to
generate a bounce to the forged sending address, is as bad as generating a
message oneself. 

---------------------------------------------------------------------------
Collected comments, in context, with sources.

Date: Fri, 9 Apr 2004 00:24:20 -0400
From: Keith Moore <[email-masked]>
Subject: Re: I-D announcement: When NOT to Bounce Email
> Keith Moore wrote:
> > 
> > quick comments:
> > 
> > 1. Title is too broad. I don't think we want to try to define a
> > complete set of criteria for when NOT to bounce email.
> 
> I aimed 'high' on the title, to catch peoples interest. 

if you stick with it, I think it will have the effect of making it harder
for your document to get approved. 

> > 2. I think it's a bit of a stretch to say that use of a false
> > return-path 'amplifies' an attack, since the message is only bounced
> > if it doesn't get to the recipient.
> 
> I agree it is probably a 'bit' of a stretch. But when you see someone's
> inbox stuffed with spurious bounces, 'amplifies' seems an
> understatement. The word was selected for 'effect'. 

the word amplifies has a technical meaning in the context of DoS attacks -
it means that the attacker gets the relay to send more messages (usually
packets) than he has sent directly. that's actually possible to do with
bounced mail messages in the sense that a bounce can be larger than the
original message - but it's stretching the term, and some people care
about precision. 

> > 3. I don't think it's appropriate to recommend what future RFCs should
> > do, since conditions will probably change before we get around to
> > revising those RFCs. Something will be done about the lack of
> > authentication in email. We don't know what it is yet. But this
> > document is probably a temporary fix rather than something to carve in
> > stone. 
> 
> You are right. I iam not sure how to say 'we need a temporary fix that
> will let people know that the RFC "must deliver or bounce" has been
> relaxed'. 

IIRC, rfc 2821 doesn't actually say that. it says the message must not be
lost for frivilous reasons. but I might not remember it accurately. 

> > 4. Section 6 is cute, but I think it would be better to leave it out.
> 
> I didn't quite know how to emphasis the fact that the religious ferver
> that is attached to 'deliver or bounce' has a root in a history where
> the object was to deliver a message (and collect a fee for doing so). I
> knew that if I just referenced the text, without quoting it, few would
> be able to look it up. I expect that it will not be in whatever the
> final product of the process it.

in the next revision, you might mark the next section "NOTE IN DRAFT - not
to be included in the published RFC" - and that way people won't argue
about it. heck, people might even ask you to include it in the final RFC -
and it might even be reasonable if given a bit more context. 
----------------
Date: Fri, 9 Apr 2004 09:22:36 -0400
From: Keith Moore <[email-masked]>
Subject: Re: I-D announcement: When NOT to Bounce Email
> Keith Moore wrote:
> > though often it's useful to respond on
> > the list to comments raised on the list - that way people see that
> > you're willing to be responsive to comments. another way to show that
> > is to revise your I-D fairly quickly and include a list of changes
> > that you made.
> 
> Thanks. I just sent something to the list to show that I am reading and
> appreciate the comments.

that should work okay.

> > > I aimed 'high' on the title, to catch peoples interest.
> > 
> > if you stick with it, I think it will have the effect of making it
> > harder for your document to get approved.
> 
> I am not stuck on it. Do you have a suggested new title?

let me think about it. for some reason I'm not feeling as picky today :)

> > > > 2. I think it's a bit of a stretch to say that use of a false
> > > > return-path
> > > > 'amplifies' an attack, since the message is only bounced if it
> > > > doesn't get to the recipient.
> > >
> > > I agree it is probably a 'bit' of a stretch. But when you see
> > > someone's inbox stuffed with spurious bounces, 'amplifies' seems an
> > > understatement. The word was selected for 'effect'.
> > 
> > the word amplifies has a technical meaning in the context of DoS
> > attacks - it means that the attacker gets the relay to send more
> > messages (usually packets) than he has sent directly. that's actually
> > possible to do with bounced mail messages in the sense that a bounce
> > can be larger than the original message - but it's stretching the
> > term, and some people care about precision.
> 
> I guess I was thinking of electronics when I used the term, rather than
> a DoS attack. In this case, the 'bounce' makes it more likely that A
> victim will get the message. I have seen cases where the program
> recognizes a virus, strips it, and sends BOTH the 'originator' and
> 'addressee' a notice. 

yeah, virus filter writers are a bit too pleased with themselves :) 

I worked with one case where a large bank had a mail gateway that bounced
to the From, to, and cc addresses - and not only that but it's way of
doing a "bounce" was to add a single obscure header to the subject message
and send it otherwise intact but with a new From address. a spammer
figured this out and was using this to amplify the message (since by
sending a single message he could cause a copy of the message to be sent
to dozens of people). Not only that but because the From address was
changed his porn advertisements appeared to come from that bank. 
> There are also cases where the virus forges the entire bounce message.

right, but this RFC won't fix that problem.

> I am not sure how to say things to bring these cases to mind.

seems like there are at least three separate problems

- virus filter writers are too eager to tout their products :)
- bounces to spam and viruses are often useless and they clog up the mail
system - some software does issue multiple messages in an error condition,
which is 
 especially bad if the recipients of those messages can be chosen by an
 attacker 

> > 
> > > > 3. I don't think it's appropriate to recommend what future RFCs
> > > > should do,
> > > > since conditions will probably change before we get around to
> > > > revising those RFCs. Something will be done about the lack of
> > > > authentication in email. We don't know what it is yet. But this
> > > > document is probably a temporary fix rather than something to
> > > > carve in stone.
> > >
> > > You are right. I am not sure how to say 'we need a temporary fix
> > > that will let people know that the RFC "must deliver or bounce" has
> > > been relaxed'.
> > 
> > IIRC, rfc 2821 doesn't actually say that. it says the message must not
> > be lost for frivilous reasons. but I might not remember it accurately.
> 
> You are correct, it says "It MUST NOT lose the message for frivolous
> reasons,....", but nowhere does it seem to suggest 'silent dropping' is
> allowed and encouraged for certain reasons.

sorry for being too tired/lazy to re-read it last night. note however that
SHOULD essentially means "you MUST do this unless you have a good reason
to not do this". what you are saying in this RFC is that if you reliably
know that a message is a virus, or that the return-path is forged, you
have a good reason to not send a nondelivery report. And that seems
perfectly consistent with SHOULD. 

I might say something like "these recommendations contradict those of RFC
2821 sections X, Y, and Z. this departure from the specification is
considered to be a temporarily measure until such time as improvements to
SMTP make it possible to authenticate the envelope return-path". 

actually that's lousy wording, but I'm operating on too little sleep.

> Do the intermediate revisions need to be submitted to the I-D editor for
> publication, or do I wait until a final form is agreed upon by the
> group? 

ietf-smtp is not an official working group anymore, so you don't exactly
have to follow rules. but the convention is to send each new revision to
the I-D editor - that way it makes it easy for people to find the latest
version. 
-----------------
From: "Daryl Odnert" <[email-masked]>
Subject: RE: I-D announcement: When NOT to Bounce Email
Date: Thu, 8 Apr 2004 15:15:53 -0700
Quick comment:

I would like to see the language in the first paragraph of section 3
broadened a little bit to include more than just "messages generated by
viruses". Shouldn't this specification allow messages that are virus
*infected* to be silently dropped, even if the message isn't generated by
a virus? What about phishing attack messages and other types of fraudulent
mail? What about other messages whose content is unquestionably malicious
or deceitful? 
------------------
From: wayne <[email-masked]>
Date: Sun, 11 Apr 2004 12:33:44 -0500

I have real mixed feelings about such a do-not-bounce proposal. On one
hand, bounces being sent to innocient third parties is a very big problem,
as you correctly point out. On the other hand, I think the LMAP proposals
can greately reduce that problem, and thus make a do-not-bounce proposal
close to irrelevant. 

>From the practical standpoint, most of these sites that are bouncing virus
warnings and email worms are using out of date software and are unlikely
to comply with the recommendations that you propose. It is my
understanding that all major anti-virus software already has terminated
sending email to probably forged envelope-from addresses in their most
recent software, and many have done so for years. 

A year ago or so ago, I would have agreed with your proposal. Today, I
mildly disagree with it because I think there are better solutions and
loosening the RFCs would simply be used as a big excuse to silently drop
email that does not have a bogus envelope-from. 

-------------------------------------------------------------------------- 
Discussion from usenet follows.
--------------------------------------------------------------------------

From: Laurence F. Sheldon, Jr. ([email-masked])
Subject: Re: Cox-clueless 
Newsgroups: news.admin.net-abuse.email
Date: 2004-04-10 08:15:54 PST 
�.
I am of of the impression that the spirit and intention of the RFC's is
well served by revising what we mean by "delivered" to allow the MTA
nearest the apparent final-destination MUA to signal OK receipt when that
is correct, and then to determine on its own what to do with the
message--to deliver it to the spool for the MUA, ... or drop it on the
floor. 

[snip analogy to landlord of apartment complex cleaning out and discarding
junk paper mail periodically from mail boxes] 

In each case there are laws that speak to misbehaviors that might be
involved--processing of the misbehaviors will address issues of intent and
such. 

but each case provides for the possibility that "discarded" without
back-trace is a possibility. 

We need to more clearly define the boundary and demarcation of
responsibility to remove the apparent requirement that the MTA do the
impossible. 
------------------------------------------------------------------------- 
From: John F Hall ([email-masked])
Subject: Re: Cox-clueless 
Newsgroups: news.admin.net-abuse.email
Date: 2004-04-10 16:33:24 PST 

bz <[email-masked]> wrote:
>Yes. It needs to be explicitly clear that it IS permissible to 'silently 
>delete' some messages. Many readers of the RFCs do not get the impression
>that messages may be considered 'delivered' before they reach the 
>addressee's inbox. 

Actually I think it needs to be stronger than that. An email cannot be
considered "delivered" until it has at least reached its intended site, so
your interpretation still imposes limitations. 

Rather the RFCs should state that when it would be harmful to the network
to propagate an email (because of a virus or trojan) than *any* MTA may
drop it and in fact shouldn't reject or bounce unless there is a reaonable
expectation that the sending address is correct. 

However it should also be made clear that this is for network protection
only and not for general email policing - the old distinction between
"abuse of the net" and "abuse on the net". We don't want to encourage
vigilantism or the equivalent of flame wars between MTAs. 

In fact perhaps the RFCs should consider viruses explicitly as a type of
email whose handling is to be specified. Rejecting/bouncing a virus is
just as bad as delivering it. Even if a bounce goes back correctly to its
originating system it might reinfect a cleaned system or infect other
systems there - there may be load balancing so that a different machine
receives it. 
---------------------------------------------------------------------------
From: Laurence F. Sheldon, Jr. ([email-masked])
Subject: Re: Cox-clueless 
Newsgroups: news.admin.net-abuse.email
Date: 2004-04-10 16:39:43 PST 

John F Hall wrote:
�.
> In fact perhaps the RFCs should consider viruses explicitly as a type of
> email whose handling is to be specified. Rejecting/bouncing a virus is
> just as bad as delivering it. Even if a bounce goes back correctly to
> its originating system it might reinfect a cleaned system or infect
> other systems there - there may be load balancing so that a different
> machine receives it.

That invites endless wars on what is virus, what is trjan, what is worm,
what is ${catchy-metaphor-du-jur}, what is feature, what is bug. 

At layers 1 and 2, I think the receiving agent has the right to drop stuff
that in its sole judgement it can not handle. That right needs to be
codified up the stack to the top (including layers 8 and 9). 
---------------------------------------------------------------------------
From: Chris U ([email-masked])
Subject: Re: Cox-clueless 
Newsgroups: news.admin.net-abuse.email
Date: 2004-04-11 01:10:06 PST 

On Sat, 10 Apr 2004 18:39:42 -0500, "Laurence F. Sheldon, Jr."
<[email-masked]> wrote:
>> In fact perhaps the RFCs should consider viruses explicitly as a type
>> of email whose handling is to be specified. Rejecting/bouncing a virus
>> is just as bad as delivering it. Even if a bounce goes back correctly
>> to its originating system it might reinfect a cleaned system or infect
>> other systems there - there may be load balancing so that a different
>> machine receives it.
>
>That invites endless wars on what is virus, what is trjan, what is worm,
>what is ${catchy-metaphor-du-jur}, what is feature, what is bug.
>
>At layers 1 and 2, I think the receiving agent has the right to drop
>stuff that in its sole judgement it can not handle. That right
>needs to be codified up the stack to the top (including layers 8 and 9).

FYI Infectious code detected and dropped.
--------------------------------------------------------------------
From: John F Hall ([email-masked])
Subject: Re: Cox-clueless 
Newsgroups: news.admin.net-abuse.email
Date: 2004-04-11 07:08:53 PST 

Laurence F. Sheldon, Jr. <[email-masked]> wrote:
�.
>That invites endless wars on what is virus, what is trjan, what is worm,
>what is ${catchy-metaphor-du-jur}, what is feature, what is bug.

Quite - and why I said it needed to be fairly strictly spelt out that
we're talking only of emails that if let through have the ability to
propagate or subvert and cause damage to the net as a whole not just
inconvenience to the recipient or his ISP. Action for the latter should be
left to them and the sender's ISP only. 

I'm afraid it's a case of "I know it when I see it", but getting the right
wording needs some time and care :-). 
-------------------------------------------------------------------- 
From: Laurence F. Sheldon, Jr. ([email-masked]) 
Subject: Re: Cox-clueless 
Newsgroups: news.admin.net-abuse.email
Date: 2004-04-11 09:41:03 PST 
John F Hall wrote:

�.
> Quite - and why I said it needed to be fairly strictly spelt out that
> we're talking only of emails that if let through have the ability to
> propagate or subvert and cause damage to the net as a whole not just
> inconvenience to the recipient or his ISP. Action for the latter
> should be left to them and the sender's ISP only.
> 
> I'm afraid it's a case of "I know it when I see it", but getting the
> right wording needs some time and care :-).

Seemd simpler to just make the rule say that the receiver is permitted to
decide what it will accept and what it won't. 
----------------------------------------------------------------- 
From: Laurence F. Sheldon, Jr. ([email-masked]) 
Subject: Re: Cox-clueless 
Newsgroups: news.admin.net-abuse.email
Date: 2004-04-11 11:05:53 PST 
bz wrote:

>>Seemd simpler to just make the rule say that the receiver is
>>permitted to decide what it will accept and what it won't.
> 
> Ah... but if by "receiver" you mean "addressee", they already have that
> capability, but by the time it gets to them, the damage is done. 

No, I mean at each juncture, the "reciever"...

> If by receiver, you mean ANY MTA that receives the message, then you
> have to consider the consequences of rejection and obligations implied
> by acceptance. 

And the consequences of acceptance and the obligations to maintain the
integrity of the system. 

> There is an obligation to deliver or notify that is implied by
> acceptance. And rejection may trigger a bounce message from the sender. 

And so it the offered object is unsatisfactory as determinined by the
reciever it should be dealt-with in the way the introduces the least
amount of harm as determined by the agent at risk. 

> There do seem to be circumstances under which acceptance SHOULD be
> followed by dropping rather than delivering or notifying. But those
> circumstances probably need to be formally set down. "Simpler" may NOT
> be the best approach in this case. 

There seems to be no circumstance where any agent should be obligated to
do or permit harm to himself or to those he serves. 
------------------------------------------------------------------- 
From: Dan Oetting ([email-masked]) 
Subject: Re: Cox-clueless 
Newsgroups: news.admin.net-abuse.email
Date: 2004-04-12 09:09:55 PST 

bz <[email-masked]> wrote:

> "Laurence F. Sheldon, Jr." <[email-masked]> wrote:
>
> > There seems to be no circumstance where any agent should be obligated
> > to do or permit harm to himself or to those he serves.
> > 
> 
�.
> 
> Back to the question at hand, current RFCs do NOT explicitly allow, much
> less recommend [though they may implicitly allow] silently dropping of
> messages, under any circumstances. I hope to see that fixed, somehow.

I agree that the RFCs need to be fixed. But not to open the gates to
silent dumping. 

Instead, the RFCs should specify that DSNs must carry a reference to the
original message so that it can be possible to determine wether a DSN is
the result of a forgery before delivering the DSN to the purported sender.

In the case where the MTA is certain that the sender address was forged,
as with a known virus or clearly identified spam, it is inappropriate to
either forward the mail to the recipient or bounce it back to the sender.
In this case, a notification should be sent to an abuse address for the
sending MTA and wait for the upstream to fix their problem. 

It is my opinion that all further communications from an MTA that forwards
viruses should be temporarily blocked until it is apparent that the
problem has been resolved. 
-------------------------------------------------------------------- 
From: Laurence F. Sheldon, Jr. ([email-masked]) 
Subject: Re: Cox-clueless 
Newsgroups: news.admin.net-abuse.email
Date: 2004-04-12 09:27:52 PST 
Dan Oetting wrote:
> I agree that the RFCs need to be fixed. But not to open the gates to 
> silent dumping.
> 
> Instead, the RFCs should specify that DSNs must carry a reference to the
> original message so that it can be possible to determine wether a DSN is
> the result of a forgery before delivering the DSN to the purported 
> sender.

As a close out, let me grant for the sake of argument that a message MUST
NEVER be silently dropped. 

Now we have some implementation issues to work on. what shall I do"

 If the 100 terabyte message comes in and I have no machine big enough
 to deal with it, even to hold onto the stuff necessary to compose and
 transmit a minimal DSN. Silly you say? OK, maybe it is.

 Suppose the message to be disposed of has headers that are known to me
 be bogus except for the stuff my machine inserted. To whom should I
 send the DSN?

 Suppose the message to be disposed of has headers that are bogus
 except for the stuff my machine inserted, but I don't know that. To
 whom should I send the DSN?

> In the case where the MTA is certain that the sender address was forged,
> as with a known virus or clearly identified spam, it is inappropriate to
> either forward the mail to the recipient or bounce it back to the 
> sender. In this case, a notification should be sent to an abuse address 
> for the sending MTA and wait for the upstream to fix their problem.

Oh, I didn't see that you had addressed that. How do we know who the
sending MTA is? 

> It is my opinion that all further communications from an MTA that 
> forwards viruses should be temporarily blocked until it is apparent that
> the problem has been resolved.

Blocked? As in, all their stuff discarded?
-------------------------------------------------------------------
From: Dan Oetting ([email-masked])
Subject: Re: Cox-clueless 
Newsgroups: news.admin.net-abuse.email
Date: 2004-04-12 11:04:34 PST 

"Laurence F. Sheldon, Jr." <[email-masked]> wrote:
�
> As a close out, let me grant for the sake of argument that a message
> MUST NEVER be silently dropped.
> 
> Now we have some implementation issues to work on. what shall I do"
> 
> If the 100 terabyte message comes in and I have no machine big enough
> to deal with it, even to hold onto the stuff necessary to compose and
> transmit a minimal DSN. Silly you say? OK, maybe it is.

Once you have accepted the DATA phase the only thing the RFC allows you to
do is wait for the end of the data before returning the final status. Of
course, there is nothing that says accidents can't happen. What if for
instance, the connection accidently got broken and your server never
managed to get past the HELO with that MTA ever again? That 100 terabyte
message would just sit there on the upstream server. 

> 
> Suppose the message to be disposed of has headers that are known to me
> be bogus except for the stuff my machine inserted. To whom should I
> send the DSN?

This could depend on how you know the headers are bogus. If the message
fits a known spam profile that should have been caught upstream you should
lart the upstream source for dumping this shit on you. 

> Suppose the message to be disposed of has headers that are bogus
> except for the stuff my machine inserted, but I don't know that. To
> whom should I send the DSN?

If you don't know for sure, you should follow the RFC and send a simple
DSN to the envelope sender with a reference to the Message ID of the
dropped message. If all DSNs contained a standard header that referenced
the Message ID of the original message it would be no problem for the
users ISP or MUA to arrange to filter out any DSNs for messages the user
did not originate. This would solve the problem of users receiving bogus
DSNs without disrupting the benefit of valid DSNs. 

�.

> Oh, I didn't see that you had addressed that. How do we know who the
> sending MTA is?

The only trusted information you have is the IP address of the server that
dumped the message on you. The notification you send would be a lart to
report the problem with the server at that address just like you would
report any other network abuse. Since you will be placing that IP address
in a temporary block list, a real MTA will find out soon enough that it
has a problem. The lart is for the benefit of network providers or ISPs
that may want to pull the plug on users that cause them grief. 

�

> Blocked? As in, all their stuff discarded?

Temporarily blocked as in:
"451 A temporary problem prevents this server from accepting your message.
Fix YOUR virus filters if you want to send email this way!" 
----------------------------------------------------------------- 
From: Laurence F. Sheldon, Jr. ([email-masked]) 
Subject: Re: Cox-clueless 
Newsgroups: news.admin.net-abuse.email
Date: 2004-04-12 15:19:24 PST 

Dan Oetting wrote:

A lot of stuff--suffice to say I don't know a way to fund all that easy
stuff, and I don't want ANY more DSN's for messages I know nothing about. 

I'm to the point that I bin the ones for messages I sent.
-----------------------------------------------------------------
From: Hal Murray ([email-masked])
Subject: Re: Cox-clueless 
Newsgroups: news.admin.net-abuse.email
Date: 2004-04-13 01:38:37 PST 

>Back to the question at hand, current RFCs do NOT explicitly allow, much
>less recommend [though they may implicitly allow] silently dropping of
>messages, under any circumstances. I hope to see that fixed, somehow.

RFCs have a long record of not keeping up with things like spam.

I wouldn't worry about violating the letter of the law if there is a good
reason, especially if you are being nice to the rest of the net rather
than being selfish. 
------------------------------------------------------------------------- 
From: Morely 'spam is theft' Dotes ([email-masked])
Subject: Re: Cox-clueless 
Newsgroups: news.admin.net-abuse.email
Date: 2004-04-13 09:20:21 PST 

bz <[email-masked]> wrote:

> I don't 'worry' but when I see a virus bounce to one of my users that is
> innocent, from a clueless sysop, and when I contact them to educate them
> that bouncing such messages just makes the problem worse, I want to be
> able to cite a BCP or RFC that makes it explicitly clear that what they
> are doing is wrong. Current RFCs ARE being interpreted as saying that
> such messages MUST be refused or bounced. 

Make it simple. Screw the RFCs - if he doesn't want all viruses that come
*from* his MTA returned to *his* mailbox, he had better stop sending them
to *your* MTA. 

Tit-for-tat, eh?
---------------------------------------------------------------------------
From: John F Hall ([email-masked])
Subject: Re: Cox-clueless 
Newsgroups: news.admin.net-abuse.email
Date: 2004-04-12 05:50:12 PST 

Laurence F. Sheldon, Jr. <[email-masked]> wrote:

>Seemd simpler to just make the rule say that the receiver is
>permitted to decide what it will accept and what it won't.

But that exists now. Any offered email may be accepted or rejected.
There is no complusion to accept. However it is considering a serious
abuse for an intermediate MTA to accept an email and not to offer it on. 
And if that offer is rejected, RFCs require a bounce to be generated and
sent back. 

The point is that in the current climate there are times when the correct
disposition *is* to accept and drop. 
----------------------------------------------------------------------- 
From: Laurence F. Sheldon, Jr. ([email-masked]) 
Subject: Re: Cox-clueless Newsgroups: news.admin.net-abuse.email
Date: 2004-04-12 07:31:18 PST 
John F Hall wrote:

> In article <yyeec.13282$wb4.12165@okepread02>,
> Laurence F. Sheldon, Jr. <[email-masked]> wrote:
> 
> 
>>Seemd simpler to just make the rule say that the receiver is
>>permitted to decide what it will accept and what it won't.
> 
> 
> But that exists now. Any offered email may be accepted or rejected.
> There is no complusion to accept. However it is considering a serious
> abuse for an intermediate MTA to accept an email and not to offer it on.
> And if that offer is rejected, RFCs require a bounce to be generated and
> sent back.
> 
> The point is that in the current climate there are times when the
> correct disposition *is* to accept and drop.
> 

Exactly so. With no forbidding rights accruing to the sender. I would
clarify that the "Intermediate MTA", if operated by or on behalf of the
addressee, is under no obligation to do anything in particular with
respect to the sender. 

Send me paper mail I don't want, I (or my agent) will put it in the
appropriate bin (here labeled "Firewood") straight away. 
-------------------------------------------------------------- 
From: Robert Bonomi ([email-masked]) 
Subject: Re: Cox-clueless 
Newsgroups: news.admin.net-abuse.email
Date: 2004-04-10 11:56:21 PST 

bz <[email-masked]> wrote:
>Satch <[email-masked]> wrote:
>> On Sat, 10 Apr 2004 09:14:52 +0000, Someone Else is alleged to have
>> said: 
>> 
>>> Uncle StoatWarbler wrote:
>>> 
>>>> On Fri, 09 Apr 2004 06:21:32 +0000, Someone Else wrote:
>>>> 
>>>> 
>>>>>It's a bit too late at night/morning to go back and check the 
>>>>>RFCs, but I can't remember a way to send a rejection after the 
>>>>>DATA phase starts, which is the only point at which you are 
>>>>>likely to detect a worm/virus/whatever.
>>>> 
>>>> 
>>>> You wait till the end of the DATA, then send 5XX REJECTED,
>>>> SPOAM/VIRUS CONTENT
>>>> 
>>>> It's perfectly legal to not give a 200 at the end of the data phase.
>>>> Think "mailbox full", etc.
>>> 
>>> At the end of DATA, you can send anything you like, but there 
>>> appear to be only 5 responses that comply with RFC 821:
>>> 
>>> DATA
>>> I: 354 -> data -> S: 250
>>> F: 552, 554, 451, 452
>>> 
>>> None of them seems appropriate for having detected a virus/worm.
>> 
>> 554: Transaction Failed.
>
>
>
>That is 'legal' but not the best idea in the current virus ridden
>environment because it will obligate the sending MTA to generate a bounce
>message to the [forged] originator. 

BZZZT! "Wrong" problem. Either the 'sending' (i.e. 'SMTP client') system
_knows_ who the *actual* sender is, and can direct the message _there_,
regardless of the 'putative sender' in the "From: " line, or they've got
no business running a mail-server. If they 'relay' for other servers, then
they should insist that those servers That they relay _for_ do *not* send
'misidentified source' mail to them for relay. 

The 'permanent' fix for this problem it to check _outgoing_ mail, and
verify that the 'from' (envelope _and_ "from: " line) addresses have been
'registered' by the user that is actually sending the mail. ('registering'
means simply 'telling' the mail-server operator that you'll be using that
'from' address. _Ideally_, they'd send a confirmation request _to_ that
address, and not let it pass until an ack is received -- that however, is
probably _gross_ overkill, and generally un-necessary) 
----------------------------------------------------------------------- 
From: Hal Murray ([email-masked]) Newsgroups:
news.admin.net-abuse.email Date: 2004-04-10 14:08:29 PST 

>I wish it were that easy, but often (for example, on our campus) there is
>an incoming mail server (MX) that 'relays' to other servers for final 
>deliver.
>
>for example, orginator@somewhere sends a messages to addressee@M
>
>Mail from somewhere --> M --> F
>Mail for addressee@M actually goes to addressee@F
>
>Everything is fine until F refuses a message. Things are still fine as
>long as originator@somewhere is the actual sender. When a virus forges 
>originator@somewhere is really the sender. 

If the problem is spam or virus, You need to move the filtering code from
F to M so M can reject rather than blindly accepting the message. 

I realize that may not be easy. But AOL is fixing their system. You can
probably fix yours. 

Disk/quota full is the only really hard case I know about. (I'm far from a
wizard in this area.) 
------------------------------------------------------------------- 
From: Someone Else ([email-masked]) 
Subject: Re: Cox-clueless  
Newsgroups: news.admin.net-abuse.email
Date: 2004-04-10 12:35:11 PST 
Satch wrote:

> On Sat, 10 Apr 2004 09:14:52 +0000, Someone Else is alleged to have
> said: 
> 
> 
>>Uncle StoatWarbler wrote:
>>
>>
>>>On Fri, 09 Apr 2004 06:21:32 +0000, Someone Else wrote:
>>>
>>>
>>>
>>>>It's a bit too late at night/morning to go back and check the 
>>>>RFCs, but I can't remember a way to send a rejection after the 
>>>>DATA phase starts, which is the only point at which you are 
>>>>likely to detect a worm/virus/whatever.
>>>
>>>
>>>You wait till the end of the DATA, then send 5XX REJECTED, SPOAM/VIRUS
>>>CONTENT
>>>
>>>It's perfectly legal to not give a 200 at the end of the data phase.
>>>Think "mailbox full", etc.
>>
>>At the end of DATA, you can send anything you like, but there 
>>appear to be only 5 responses that comply with RFC 821:
>>
>> DATA
>> I: 354 -> data -> S: 250
>> F: 552, 554, 451, 452
>>
>>None of them seems appropriate for having detected a virus/worm.
[snip]

> - If the verb is initially accepted and the 354 reply issued, the
> DATA command should fail only if the mail transaction was
> incomplete (for example, no recipients), or if resources were
> unavailable (including, of course, the server unexpectedly
> becoming unavailable), or if the server determines that the
> message should be rejected for policy or other reasons.
> 
> [end quote]
> 
> See that last sentence? Rejected FOR POLICY OR OTHER REASONS. 

Thanks. I do now (:-). Vernon had pointed me at RFC 821, which does not
seem to contain that extra proviso. I skimmed RFC 2821, and especially
Sec. 4.1.1.4 (p 33), which appears to follow RFC 821, with elaborations. I
didn't catch Sec. 3.3 (p18), which you quote above. 

[snip]
> Here is another interesting tidbit:
> 
> When an SMTP server returns a permanent error status (5yz) code after
> the DATA command is completely with <CRLF>.<CRLF>, it MUST NOT make
> any subsequent attempt to deliver the message. As with temporary
> error status codes, the SMTP client retains responsibility for the
> message, but SHOULD not again attempt delivery to the same server
> without user review and intervention of the message.
 >
> So any SMTP client that doesn't take 554 or 550 or ANY 5xy for an answer
> is RFC-noncompliant. It makes the "right code" argument moot, as the
> word MUST overrides all such concerns on the part of the sender. It MUST
> NOT TRY AGAIN. Period.

Actually, if you look closely, the "MUST NOT" refers to the server
attempting to deliver a message after having returned a 5xy code. The
paragraph you quoted says that the client "SHOULD" not try again. 

But I agree. Whatever the RFCs say about what codes may be returned, a 5xy
should be treated as "don't try that again". 
-------------------------------------------------------------------- 
From: Morely 'I drank what?' Dotes ([email-masked]) 
Subject: Re: Cox-clueless Newsgroups: news.admin.net-abuse.email
Date: 2004-04-10 17:50:06 PST 
While gargling concrete on 10 Apr 2004, Someone Else 
<[email-masked]> wrote:

> At the end of DATA, you can send anything you like, but there 
> appear to be only 5 responses that comply with RFC 821:
> 
> DATA
> I: 354 -> data -> S: 250
> F: 552, 554, 451, 452
> 
> None of them seems appropriate for having detected a virus/worm.

Either 552 of 554 seem appropriate to me.

The purpose of *my* MTA is to accept legitimate email for my users.
Sending a virus/worm/trojan/spam constitutes failure. 

YMMV.
------------------------------------------------------------------
From: Vernon Schryver ([email-masked])
Subject: Re: Cox-clueless 
Newsgroups: news.admin.net-abuse.email
Date: 2004-04-09 07:18:14 PST 
In article <[email-masked]>,
Someone Else <[email-masked]> wrote:
> ...
>It's a bit too late at night/morning to go back and check the 
>RFCs, but I can't remember a way to send a rejection after the 
>DATA phase starts, which is the only point at which you are 
>likely to detect a worm/virus/whatever. 
>If I'm wrong, there's no need to waste your time with details, 
>I'll look them up over the weekend. Just tell me I'm wrong and 
>point me to the RFC.

See the discussion of the DATA command in RFC 821. The DATA command is
like any other SMTP command sent by the SMTP client to the SMTP server. It
must be answered by the SMTP server with the usual SMTP status response
starting with a three digit number. If the SMTP server answers with a 5yz
response, then the SMTP client must give up on the message entirely. If
the SMTP server gives a 4yz response, then the SMTP client should try
again later. RFC 2821 suggests a 30 minute retransmission delay. 

Spam body filters I've worked on have been answering DATA commands with
5yz or 4yz responses since 1996 or 1997. The DCC is my current project. It
was used on more than 120 million mail messages last Wednesday at about
20,000 sites. 

Years ago many users and system administrators were confused about SMTP
DATA commands, but it is now fairly rare to find someone who still
contradicts RFC 821. 
--------------------------------------------------------------------- 
From: Vernon Schryver ([email-masked]) 
Subject: Re: Cox-clueless
Newsgroups: news.admin.net-abuse.email
Date: 2004-04-10 06:03:17 PST 
Someone Else <[email-masked]> wrote:

> ...
>Thank you. I believe RFC 821 confirms my recollection. RFC 2821 
>may have modified things, but since you point to RFC 821 I'll 
>stick with that. The DATA command is _not_ "like any other SMTP 
>command sent by the SMTP client to the SMTP server." There are 
>only 5 permissible responses to the end of data (<CRLF>.<CRLF>). 
> From "4.3. SEQUENCING OF COMMANDS AND REPLIES":

Why are you advocating such silly nonsense? What is your agenda? Are you
merely trying to recover from the obviously wrong claim that it is
impossible to reject the DATA command? 

By any chance have you worked on one of the grossy broken SMTP clients
that just assumed no response other than 250 OK is possible for DATA and
that ignore all 4yz and 5yz responses? Hotmail did that for years. There
still some installations of such junk out there. 

>I might have been more precise about the meaning of "rejection", 
>but none of the above responses would be appropriate on having 
>detected a virus/worm. You might argue for 554, except that RFC 
>821 is fairly explicit about that:
>
>"The end of mail data indication requires that the receiver
>must now process the stored mail transaction information.
>This processing consumes the information in the reverse-path
>buffer, the forward-path buffer, and the mail data buffer,
>and on the completion of this command these buffers are
>cleared. If the processing is successful the receiver must
>send an OK reply. If the processing fails completely the
>receiver must send a failure reply."
>
>If the data was successfully processed, "the receiver _must_ 
>[emphasis added] send an OK reply."
>
>How do you send a failure if you successfully processed the data 
>and discovered a virus/worm?

If you discover a virus/worm, if your file system is too sick to let you
collect the message, or anything else that prevents you from successfully
processing the data then you must emit the most appropriate error
response. 

>It would appear that anyone who, at the end of data, sends a 
>response other than 250, 552, 554, 451, or 452, or sends one of 
>them in response to a successfully received worm/virus, is 
>contradicting RFC 821.

It is incredibly silly to claim that since there is no 5yz for "virus/worm
found" you must therefore generate a bounce instead of a rejection. 

It's an insult to Jon Postel's memory to imply that he would have intended
that all errors must generated DSNs except those you in your anonymous
authority determine fit the RFC 821 error strings. 
-------------------------------------------------------------------- 
From: Someone Else ([email-masked]) 
Subject: Re: Cox-clueless 
Newsgroups: news.admin.net-abuse.email
Date: 2004-04-10 13:12:31 PST 
Vernon Schryver wrote:

> In article <[email-masked]>,
> Someone Else <[email-masked]> wrote:
> 
> 
>>...
>>Thank you. I believe RFC 821 confirms my recollection. RFC 2821 
>>may have modified things, but since you point to RFC 821 I'll 
>>stick with that. The DATA command is _not_ "like any other SMTP 
>>command sent by the SMTP client to the SMTP server." There are 
>>only 5 permissible responses to the end of data (<CRLF>.<CRLF>). 
>>From "4.3. SEQUENCING OF COMMANDS AND REPLIES":
> 
> 
> Why are you advocating such silly nonsense? What is your agenda?
> Are you merely trying to recover from the obviously wrong claim
> that it is impossible to reject the DATA command?

In order:

a) I am not advocating anything. I am merely pointing out that RFC 821
does not appear to provide a way out (for rejecting worms/viruses) after
the start of data. Satch pointed out elsewhere that RFC 2821 does (550),
but you pointed me at RFC 821, which does not allow 550 after start of
data. b) My agenda is to be anointed Emperor of the Universe. So far, it
is not progressing well. 

c) I am not trying to recover from anything. I never claimed that it was
impossible to reject the DATA command. That's easy: 
 DATA
 I: 354 -> data -> S: 250
 F: 552, 554, 451, 452
 F: 451, 554
 E: 500, 501, 503, 421
What I said was that _I could not remember_ a way to reject [based on
content] _after_ accepting the DATA command, thereby allowing the start of
data. You pointed me at RFC 821, which does not provide such a mechanism. 

> By any chance have you worked on one of the grossy broken SMTP clients
> that just assumed no response other than 250 OK is possible for DATA
> and that ignore all 4yz and 5yz responses? Hotmail did that for years.
> There still some installations of such junk out there.

Nope, never worked on any SMTP clients, broken or otherwise.

>>I might have been more precise about the meaning of "rejection", 
>>but none of the above responses would be appropriate on having 
>>detected a virus/worm. You might argue for 554, except that RFC 
>>821 is fairly explicit about that:
>>
>>"The end of mail data indication requires that the receiver
>>must now process the stored mail transaction information.
>>This processing consumes the information in the reverse-path
>>buffer, the forward-path buffer, and the mail data buffer,
>>and on the completion of this command these buffers are
>>cleared. If the processing is successful the receiver must
>>send an OK reply. If the processing fails completely the
>>receiver must send a failure reply."
>>
>>If the data was successfully processed, "the receiver _must_ 
>>[emphasis added] send an OK reply."
>>
>>How do you send a failure if you successfully processed the data 
>>and discovered a virus/worm?
> 
> 
> If you discover a virus/worm, if your file system is too sick to
> let you collect the message, or anything else that prevents you
> from successfully processing the data then you must emit the most
> appropriate error response.

That's not what RFC 821 says. RFC 2821 permits failure for policy reasons,
but not RFC 821, which is where you pointed me. If you successfully
received the data and were able to process it (e.g., to discover that it
was a worm), then the processing was successful. You may not want what you
got, but you processed it successfully. 

>>It would appear that anyone who, at the end of data, sends a 
>>response other than 250, 552, 554, 451, or 452, or sends one of 
>>them in response to a successfully received worm/virus, is 
>>contradicting RFC 821.
> 
> 
> It is incredibly silly to claim that since there is no 5yz for
> "virus/worm found" you must therefore generate a bounce instead
> of a rejection.

It is incredibly silly to claim that RFC 821 provides for a mechanism to
send a failure based on content. I never said that you must generate a
bounce instead of a rejection on detecting a virus. I said that RFC 821
left the server in a bind. RFC 2821 appears to have corrected that. 

> It's an insult to Jon Postel's memory to imply that he would have
> intended that all errors must generated DSNs except those you in your
> anonymous authority determine fit the RFC 821 error strings.
> 
> 
> Vernon Schryver [email-masked]

I expect JP's memory will get over it, even if you can't. Besides, my
anonymous authority has yet to be confirmed. 
------------------------------------------------------------------ 
From: Vernon Schryver ([email-masked]) 
Subject: Re: Cox-clueless 
Newsgroups: news.admin.net-abuse.email
Date: 2004-04-10 14:17:25 PST 
Someone Else <[email-masked]> wrote:
> ...
>> If you discover a virus/worm, if your file system is too sick to
>> let you collect the message, or anything else that prevents you
>> from successfully processing the data then you must emit the most
>> appropriate error response.
>
>That's not what RFC 821 says. 

Nonsense! If you can't proceed, then you can't go on and must not pretend.
The only question is what reason or excuse you give the SMTP client. 

RFCs were and are still not written in the legalistic styles of other
standards organizations. The primary Internet protocol rule of "Be
conservative in what you send and generous in what you accept" must be
applied while reading RFCs. Or shorter, "you gotta have common sense." 

> RFC 2821 permits failure for 
>policy reasons, but not RFC 821, which is where you pointed me. 
>If you successfully received the data and were able to process 
>it (e.g., to discover that it was a worm), then the processing 
>was successful. You may not want what you got, but you processed 
>it successfully.

That's a bogus notion of "processed." If Jon had meant merely "received,"
then he would have written "received." 

> ...
>mechanism to send a failure based on content. I never said that 
>you must generate a bounce instead of a rejection on detecting a 
>virus. I said that RFC 821 left the server in a bind. RFC 2821 
>appears to have corrected that.

Behind many RFC "corrections" is grumbling of the form "How can people be
so perversely stupid that they insist on twisting the clear intention of
those words into that obvious nonsense?" 
---------------------------------------------------------------- From:
Someone Else ([email-masked]) 
Subject: Re: Cox-clueless 
Newsgroups: news.admin.net-abuse.email
Date: 2004-04-11 03:27:17 PST 
Vernon Schryver wrote:
> In article <[email-masked]>,
> Someone Else <[email-masked]> wrote:

[snip]

> RFCs were and are still not written in the legalistic styles of
> other standards organizations. The primary Internet protocol rule
> of "Be conservative in what you send and generous in what you accept"
> must be applied while reading RFCs. Or shorter, "you gotta have
> common sense."

And this from the man who once (implicitly) called me a "posuer" for
writing "RDNS" instead of "reverse DNS" (:-). 

[snip]

> Behind many RFC "corrections" is grumbling of the form "How can
> people be so perversely stupid that they insist on twisting the
> clear intention of those words into that obvious nonsense?"

I've heard the same thing said of many compilers. To paraphrase: Why does
the compiler give an error message saying "I know exactly what you want me
to do, but I'm not going to do it."? (As in "missing ';' on line 723".)
When computers are involved, precision becomes important. 
------------------------------------------------------------------- 
From: Vernon Schryver ([email-masked]) 
Subject: Re: Cox-clueless 
Newsgroups: news.admin.net-abuse.email
Date: 2004-04-11 11:00:27 PST 
Someone Else <[email-masked]> wrote:

>> Behind many RFC "corrections" is grumbling of the form "How can
>> people be so perversely stupid that they insist on twisting the
>> clear intention of those words into that obvious nonsense?" 
>I've heard the same thing said of many compilers. To paraphrase: 
>Why does the compiler give an error message saying "I know 
>exactly what you want me to do, but I'm not going to do it."? 
>(As in "missing ';' on line 723".) When computers are involved, 
>precision becomes important.

Computers were not at issue in this thread. Compilers don't read RFCs or
write SMTP clients and servers. Not even ITU standards can be fed to
compilers to produce x.400 implementations. Only people invent
recollections of restrictions in RFCs instead of making the effort to
read, understand, and check the last decade of industry practice. Only we
twist the clear intentions of the words in RFCs into preverse pretzels to
avoid the terrible catastrophies of needing to say "I don't know" or "I'm
wrong." 

Too much of my usenet experience goes according to this script:
 - read an article
 - grumble "what obviously silly rubbish. why can't they bother
 to check the facts?"
 - compose a pointed rejoinder
You don't see many of those, because I often continue with:
 - check RFCs, system source, etc. to include authorities in the
 rejoinder. - discover I'm wrong.

In my world, there's no shame in being wrong, but plenty in being unable
to admit it and instead inventing meanings for "processed." When
interviewing people for a job, one of my two main tactics is to see if the
candidate has trouble saying "I don't know." I've found that people who
stumble on those words turn out to be worse than useless to have around.
Perhaps if my interests were in sales, marketing, or even management, this
test would be invalid. 
-------------------------------------------------------- 
From: Morely 'I drank what?' Dotes ([email-masked]) 
Subject: Re: Cox-clueless
Newsgroups: news.admin.net-abuse.email
Date: 2004-04-10 17:50:06 PST 
While gargling concrete on 10 Apr 2004, Someone Else 
<[email-masked]> wrote:

> How do you send a failure if you successfully processed the data 
> and discovered a virus/worm?

I class that as a failure. Problem solved.
----------------------------------------------------------------
From: Norman L. DeForest ([email-masked])
Subject: Re: Cox-clueless 
Newsgroups: news.admin.net-abuse.email
Date: 2004-04-10 17:40:17 PST 
On Sat, 10 Apr 2004, Someone Else wrote:

> Norman L. DeForest wrote: [snip]
> > See RFC 2821 [snip]
> > : E: 552, 554, 451, 452
> > ^^^^^^^^^^^^^^^^^^^^^ error codes *after*
> > the data. [snip]
> The responses that are acceptable _after_ the data is received 
> are defined as:
> 
> 250 Requested mail action okay, completed
> 451 Requested action aborted: local error in processing
> 452 Requested action not taken: insufficient system storage
> 552 Requested mail action aborted: exceeded storage allocation
> 554 Transaction failed
> 
> None of these is appropriate in response to undesired content.

Not even 554? It doesn't say *why* the transaction failed. It is mentioned
as an appropriate response for other SMTP commands when the argument of
the command is invalid. One could argue that the data following a DATA
command is the "argument" of the command and invalid data (undesired
content) *is* an invalid argument. 

Of course, my argument might get me acused of doing the same thing as was
done by the guy who took an axe to his greedy relatives urging him to
change his will.[1] 

[1] Fcyvggvat urvef.[2]
[2] Use the Lumber Cartel Sooper Sekrit Decoder Ring.[3]
[3] TINLCSSDR and it's not at:
 http://www.chebucto.ns.ca/~af380/Tips.html#lc13
-----------------------------------------------------------
From: Someone Else ([email-masked])
Subject: Re: Cox-clueless 
Newsgroups: news.admin.net-abuse.email
Date: 2004-04-10 01:59:43 PST 
John Doherty wrote:
> In article <[email-masked]>, 
> Someone Else wrote:
>
>>I can't remember a way to send a rejection after the DATA phase
>>starts, which is the only point at which you are likely to detect a
>>worm/virus/whatever.
>

[snip]

> There's no general problem with issuing a permanent failure after a
> message is completely received: the key is that the detection and 
> rejection has to be hooked into the MTA. That's what milters are for.

Please see my response to Vernon Schryver, elsewhere in this thread
(Message-ID: <[email-masked]>)

> If the worm/virus/whatever detection doesn't start until after the MTA 
> has received the message, then obviously, the MTA has received (i.e., 
> not rejected) the message.

True. At that point the MTA is stuck, but it appears that the MTA is stuck
even earlier, after agreeing to accept the data. Of course the MTA could
still issue a failure, but it would have to lie about the reason. 
---------------------------------------------------------------
From: Someone Else ([email-masked]) 
Subject: Re: Cox-clueless 
Newsgroups: news.admin.net-abuse.email
Date: 2004-04-10 13:18:34 PST 
John Doherty wrote:

> In article <[email-masked]>, 
> Someone Else wrote:
> 
> 
>>>If the worm/virus/whatever detection doesn't start until after the
>>>MTA has received the message, then obviously, the MTA has received
>>>(i.e., not rejected) the message.
>>
>>True. At that point the MTA is stuck, but it appears that the
>>MTA is stuck even earlier, after agreeing to accept the data. Of
>>course the MTA could still issue a failure, but it would have to
>>lie about the reason.
> 
> 
> I don't see that that's true, and even if it were, I'm not about to 
> accept malware just because I can't find a perfectly suitable error 
> code.

Of course not. I was merely pointing out that RFC 821 left the MTA in a
bind. It has later been pointed out to me (several times (:-)) that RFC
2821 fixed the problem. 

> 
> From RFC 2821:
> 
> 550 Requested action not taken: mailbox unavailable (e.g., mailbox
> not found, no access, or command rejected for policy reasons)
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> And I have a policy of not accepting malware if I can help it, so a 
> 550 rejection is just fine.
> 
> --
> 

Absolutely. Although RFC 2821 should probably be modified to include 550
as a valid response to end of data. As it stands: 

 DATA
 I: 354 -> data -> S: 250
 E: 552, 554, 451, 452
 E: 451, 554, 503
---------------------------------------------------------------------------
From: Someone Else ([email-masked])
Subject: Re: Cox-clueless 
Newsgroups: news.admin.net-abuse.email
Date: 2004-04-10 19:54:55 PST 

John Doherty wrote:
> In article <[email-masked]>, 
> Someone Else wrote:
[snip]

>>Absolutely. Although RFC 2821 should probably be modified to
>>include 550 as a valid response to end of data. As it stands:
>>
>> DATA
>> I: 354 -> data -> S: 250
>> E: 552, 554, 451, 452
>> E: 451, 554, 503
> 
> 
> But that is not meant to be an exhaustive list, implying that any 
> other response is invalid.
> 
> That section begins:
> 
> 4.3.2 Command-Reply Sequences
> 
> Each command is listed with its usual possible replies.
> 
> Note "usual possible," not "all possible." In other words, the diagram 
> above shouldn't be taken to mean that 552 and 554 are the only valid 
> 5yz responses at that point.
> 
> --
> 

Ahh... Another subtle difference between RFC 2821 and RFC 821, which says:

COMMAND-REPLY SEQUENCES

 Each command is listed with its possible replies. 
[...] This listing forms the basis for the State Diagrams in 
Section 4.4.

No "usually", and a fairly explicit reliance on those being all possible
responses. Of course, RFC 2821 supersedes that. From: Jay Stuler
([email-masked]) Subject: Re: Cox-clueless 
Newsgroups: news.admin.net-abuse.email
Date: 2004-04-08 19:40:21 PST 
"Scott Wertz" <[email-masked]> wrote:
> fudo wrote:
> > So, I got one of those "your email was not delivered because it
> > contained a virus" messages from Cox this morning. Sent them back a
> > polite message asking them to turn off this useless feature, and got
> > this:
> >
>
> Yeah, yeah, yeah.
>
> You bitch about getting notified for something you never sent, and the
> guy around the corner from you is bitching that it's a violation of RFC
> something-or-other when a mail server ditched his message without
> notification.
>
> Quit bitching and offer a solution.

Solution:

When it's known to be a virus/trojan/worm, don't send a notification to
the supposed sender. Otherwise, do.
---------------------------------------------------------------------
From: Buss Error ([email-masked])
Subject: Re: Cox-clueless 
Newsgroups: news.admin.net-abuse.email
Date: 2004-04-08 22:49:44 PST 
"Jay Stuler" <[email-masked]> wrote: 
> Solution:
> 
> When it's known to be a virus/trojan/worm, don't send a notification
> to the supposed sender.
> Otherwise, do.

www.mailscanner.info

Search for the option "silent virus".

It's not perfect because it must be updated manually.
I've set my installation to never notify on any virus.

Once a day I search to mail queue and lart the admin if I'm getting more
than 500 or so from a single IP. I notifed SWBELL the other day, sending
along a 40K log grep. The virus infected computer stopped sending the
virus within 30 minutes. 

I think I prefaced the email with "Please stop this sillyness." or words
to that effect. 
---------------------------------------------------------------------- 
From: Duncan Hill ([email-masked]) Subject: Re: Cox-clueless 
Newsgroups: news.admin.net-abuse.email
Date: 2004-04-09 07:53:53 PST 
Buss Error wrote:
> www.mailscanner.info
> 
> Search for the option "silent virus".
> 
> It's not perfect because it must be updated manually.
> I've set my installation to never notify on any virus.

IMO, the solution in Amavisd-new is neater. If the virus doesn't match a
list of know types of virus/worm that don't spoof the sender, don't
notify. Less hassle to maintain.
----------------------------------------------------------------
From: Tony Roza ([email-masked])
Subject: Re: Cox-clueless 
Newsgroups: news.admin.net-abuse.email
Date: 2004-04-08 22:58:05 PST 
"fudo" <[email-masked]> wrote in message:
> In article <[email-masked]>,
> "Morely 'I drank what?' Dotes" <[email-masked]> wrote:
> <snip>
> There seems to be some mis-understanding here, for which I take full
> credit. To wit: I am *not* a Cox customer. Cox is sending me an alert
> about a virus that supposedly *came from me*. As I said in my first
> email to them, we all know that the purported sending address is forged.
> Sending an alert to that address is just, well, stupid. And then you add
> to that a support drone who can't figure out that I'm not a Cox
> customer. Really, do I have to tell them "I'm not your customer, don't
> send me alerts"? Do I have to explain in minute detail why sending an
> alert to a forged addy is stupid? If I have to do all that, maybe they
> should just hire me, eh? I could hardly do worse...

The tech support people at Cox may not be able to understand that an email
address can be forged. I have not had any dealing with Cox on these
matters but, i found out that AOL email support is clueless. 

Last fall, i had a domain forged by a spammer who was hitting AOL. After
about 1000 bounces, I called AOL to ask if they could do something about
the flow coming from their servers. I received nothing but an attitude
from their email support crew. My workaround was to write a script that
discards AOL bounces sent to unused email addresses. An interesting note
is there were no bounces from any host other than AOL. 

Back to the virus "bounce" ... i have received virus warnings from hosts
that not only sent a warning to the forged email address but returned the
virus as an attachment! Might say that an unsecured Microsoft box
effectively turned a Linux box into a virus distribution center.
Cooperative computing! 
-------------------------------------------------------------- 
From: John F Hall ([email-masked]) Subject: Re: Cox-clueless 
Newsgroups: news.admin.net-abuse.email
Date: 2004-04-10 04:34:40 PST 
In article <[email-masked]>,
Morely 'spam is theft' Dotes <[email-masked]> wrote:
>bz <[email-masked]> wrote: 
>
>> Uncle StoatWarbler <[email-masked]>: 
>>> If the message is refused during the SMTP phase then it doesn't need
>>> to be dropped OR bounced.
>> 
>> If it is _refused_, the SENDING MTA will [normally] originate a bounce 
>> message. 
>
>True; but that's not what's being discussed.

So this is a case where refusing is the *worse* option. If one's already
received the email, which one must have to have identified a virus, then
just drop it. Refusing, and so causing the sending MTA to generate a
bounce to the forged sending address, is as bad as generating a message
oneself. 

Date: Mon, 19 Apr 2004 09:33:27 -0400
From: "Richard O. Hammer" <[email-masked]>
To: [email-masked]
Subject: seeking discussion on network protocols and property rights
Sender: [email-masked]

I would like to enter into a discussion which seeks to find free 
market solutions to the present problems of Internet lawlessness, 
problems such as spam, viruses, and abuse of intellectual property.

I write to ask if anyone on this list can point me to such a 
discussion, forum, or blog.  I am considering starting a blog for this 
purpose, but first I want to know what already exists.

The discussion I seek will be roughly the overlap of the following 
subjects:
  - network protocols
  - economics, and specifically transactions costs
  - free market business plans (i.e. NOT intervention by the state)
  - property rights
  - spontaneous order

The purpose of this list ([email-masked]) relates somewhat to what 
I am seeking.  But there are differences.  I believe it would be 
inappropriate to start an extended discussion of my topic on this 
list.  I ask mainly if anybody can point me to existing discussions 
which relate more closely to the topic I outline.

Thank you,
Richard O. Hammer (Rich)

my present project: <http://mailscreen.net>
resume: <http://trilug.org/~rh/resume.html>

Date: Sat, 17 Apr 2004 15:40:26 -0700 (PDT)
From: [email-masked]
Subject: Re: I-D ACTION:draft-arun-ncc-smtp-01.txt
To: Arnt Gulbrandsen <[email-masked]>
Cc: Valdis =?utf-8?q?Kl=C4=93tnieks?= <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

> Valdis Klētnieks writes:
> > Personally, I just filter duplicates based on Message-ID - but that's
> > a total non-starter for people who don't have essentially free
> > last-hop bandwidth.

> By my logs, more bandwidth is used by random noise (scans for IIS holes,
> popup spam, etc) than by TOTAL email, not to mention message
> duplicates. Is that so unusual? Or are people worrying about a small
> problem again and ignoring the biggies?

I receive over 10 viruses for every legitimate or spam email. So yes, I see
this as at best a very weak solution to unwanted bandwidth utilization. The
intent as I see it is more to provide a convenience feature.

				Ned

From: Arnt Gulbrandsen <[email-masked]>
To: Valdis =?utf-8?q?Kl=C4=93tnieks?= <[email-masked]>
Subject: Re: I-D ACTION:draft-arun-ncc-smtp-01.txt
Cc: [email-masked], [email-masked]
Date: Tue, 13 Apr 2004 11:58:25 +0200
Sender: [email-masked]

Valdis Klētnieks writes:
> Personally, I just filter duplicates based on Message-ID - but that's 
> a total non-starter for people who don't have essentially free 
> last-hop bandwidth.

By my logs, more bandwidth is used by random noise (scans for IIS holes, 
popup spam, etc) than by TOTAL email, not to mention message 
duplicates. Is that so unusual? Or are people worrying about a small 
problem again and ignoring the biggies?

Arnt

Date: Mon, 12 Apr 2004 23:21:43 -0400
From: Keith Moore <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-arun-ncc-smtp-01.txt
Sender: [email-masked]

> > > If we're trying to provide advisory eliminate-dups, then a better thing
> > > to do might be to dust off Bernstein's Mail-Followup-To: proposal from
> > > http://
> > > cr.yp.to/proto/replyto.html - that's already got *some* MUA traction
> > > deployed, and I know of several other MUAs that don't support it mostly
> > > because it was never progressed down the RFC path.
> > 
> > that doesn't solve the problem - it just makes things more complex.
> 
> I don't think Dan was trying to solve the whole problem either, but merely
> address one somewhat semi-solvable subset...

perhaps not.  but it strikes me as a fairly awkward way to solve the "group
replies don't go to the right place" problem, and an even more awkward way to
solve the "I don't want to get multiple copies" problem.  I have some notes on
this somewhere; maybe I can dig them up. 
 
> I suspect that without knowing if the current draft is trying to address the
> problem of "keep one person in the dark", or "suppress duplicates", or some
> other problem, we can't really comment more fully on the draft....

I agree.

-- 
Regime Change 2004 - better late than never. 

To: "D. J. Bernstein" <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-arun-ncc-smtp-01.txt 
From: [email-masked]
Date: Mon, 12 Apr 2004 21:31:08 -0400
Sender: [email-masked]

--==_Exmh_376490856P
Content-Type: text/plain; charset=us-ascii

On Tue, 13 Apr 2004 00:54:09 -0000, "D. J. Bernstein" <[email-masked]>  said:
> 
> [email-masked] writes:
> > If we're trying to provide advisory eliminate-dups, then a better thing to 
do
> > might be to dust off Bernstein's Mail-Followup-To: proposal from http://
> > cr.yp.to/proto/replyto.html
> 
> ``Dust off''? A Google search for Mail-Followup-To returns nearly half a
> million hits. I see Mail-Followup-To in a large fraction of mailing-list
> messages. You're entitled to speculate that IETF action would increase
> use of Mail-Followup-To, but you're not entitled to pretend that IETF
> action is a prerequisite to widespread use of the protocol.

There was an Internet-Draft on it, which expired.  There's no current I-D,
nor is there an RFC.  In the context of the working group, getting that draft
back into current status would indeed be dusting off.

You'll note that I *did* specifically mention it's in current usage - what's
getting dusted off is the RFC status, not the header itself.

--==_Exmh_376490856P
Content-Type: application/pgp-signature

--==_Exmh_376490856P--

Date: 13 Apr 2004 00:54:09 -0000
Mail-Followup-To: [email-masked]
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-arun-ncc-smtp-01.txt
Sender: [email-masked]

[email-masked] writes:
> If we're trying to provide advisory eliminate-dups, then a better thing to do
> might be to dust off Bernstein's Mail-Followup-To: proposal from http://
> cr.yp.to/proto/replyto.html

``Dust off''? A Google search for Mail-Followup-To returns nearly half a
million hits. I see Mail-Followup-To in a large fraction of mailing-list
messages. You're entitled to speculate that IETF action would increase
use of Mail-Followup-To, but you're not entitled to pretend that IETF
action is a prerequisite to widespread use of the protocol.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

To: Keith Moore <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-arun-ncc-smtp-01.txt 
From: [email-masked]
Date: Mon, 12 Apr 2004 20:24:38 -0400
Sender: [email-masked]

--==_Exmh_49711436P
Content-Type: text/plain; charset=us-ascii

On Mon, 12 Apr 2004 19:31:10 EDT, Keith Moore said:
> > If we're trying to provide advisory eliminate-dups, then a better thing to do
> > might be to dust off Bernstein's Mail-Followup-To: proposal from http://
> > cr.yp.to/proto/replyto.html - that's already got *some* MUA traction deployed,
> > and I know of several other MUAs that don't support it mostly because it was
> > never progressed down the RFC path.
> 
> that doesn't solve the problem - it just makes things more complex.

I don't think Dan was trying to solve the whole problem either, but merely
address one somewhat semi-solvable subset...

I suspect that without knowing if the current draft is trying to address the
problem of "keep one person in the dark", or "suppress duplicates", or some
other problem, we can't really comment more fully on the draft....

--==_Exmh_49711436P
Content-Type: application/pgp-signature

--==_Exmh_49711436P--

Date: Mon, 12 Apr 2004 19:31:10 -0400
From: Keith Moore <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-arun-ncc-smtp-01.txt
Sender: [email-masked]

> If we're trying to provide advisory eliminate-dups, then a better thing to do
> might be to dust off Bernstein's Mail-Followup-To: proposal from http://
> cr.yp.to/proto/replyto.html - that's already got *some* MUA traction deployed,
> and I know of several other MUAs that don't support it mostly because it was
> never progressed down the RFC path.

that doesn't solve the problem - it just makes things more complex.

Date: Mon, 12 Apr 2004 19:29:26 -0400
From: Keith Moore <[email-masked]>
To: [email-masked] (Kai Henningsen)
Cc: [email-masked], [email-masked]
Subject: Re: value of deferred RCPT responses?
Sender: [email-masked]

> Well, MTAs already *do* check message content before answering after  
> <CRLF>.<CRLF>. I really don't think the ability to do per-user responses  
> will make a significant difference there.

yes, but how often do they apply criteria on a per-user basis while they are
doing this?  

-- 
Regime Change 2004 - better late than never. 

Date: 11 Apr 2004 20:38:00 +0200
From: [email-masked] (Kai Henningsen)
To: [email-masked]
Subject: Re: value of deferred RCPT responses?
Organization: Organisation? Me?! Are you kidding?
Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail.
Sender: [email-masked]

[email-masked] (Keith Moore)  wrote on 03.04.04 in <[email-masked]>:

> I suppose there is a third kind - those that can be caught on-the-fly,
> while the message is being received, but which due to SMTP limitations
> cannot be reported until after the message is received.  Still I have
> to wonder how many MTAs are going to get restructured so that all of
> the testing for each of the recipients is done concurrently while the
> message is being received.  To do this and still minimize the potential
> for races strikes me as a coding nightmare unless you seriously
> constrain what kinds of criteria can be applied on a per-recipient
> basis.

Well, MTAs already *do* check message content before answering after  
<CRLF>.<CRLF>. I really don't think the ability to do per-user responses  
will make a significant difference there.

MfG Kai

To: [email-masked]
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-arun-ncc-smtp-01.txt 
From: [email-masked]
Date: Mon, 12 Apr 2004 14:48:39 -0400
Sender: [email-masked]

--==_Exmh_-1714315538P
Content-Type: text/plain; charset=us-ascii

On Mon, 12 Apr 2004 10:36:54 PDT, [email-masked] said:

> This makes me wonder if a modified version of this proposal would be
> acceptable. Suppose the applicability of ncc was limited to list processors.
> We've long argued that list procesors operate at the MUA level and not at the
> MTA level. A mechanism that provides information to a list processor
> (specifically, it tells it to exclude certain addresses from the expansion)
> could legtimately be done with a header.

That has possibilities, but....

> The real question here is what this mechanism is intended to be used for. (The
> draft really doesn't say.) If the intent is to provide a security mechanism
> where specific people are reliably prevented from receiving mail as well as
> being prevented from seeing that they were excluded, then an SMTP extension is
> the only way to do it and the chances of deployment are negligable.

Remember - all it takes is one bozo with a broken/old MUA to do a 'reply all',
and the game is over (the same information leakage issues as the Bcc: issues
discussed in the second paragraph of RFC2821, section 5 (security
considreations)).

Trying to reliably make sure that person A doesn't find out that person B got a
copy of a mail is, in general, a lost cause.

> If, on the other hand, the intent is to provide an advisory mechanism to
> attempt to block unnecessary message copies in some cases, where it is
> understood that the block isn't going to be 100% reliable and where it is
> understood that the blocked individual may be aware of the blocking, then a
> simple header could be defined. The question then is whether or not such a
> mechanism is useful enough to bother. (I have no religion about this personally
> - extra copies of messages don't bother me although I realize they bother other
> people a lot.)

Personally, I just filter duplicates based on Message-ID - but that's a total
non-starter for people who don't have essentially free last-hop bandwidth.

If we're trying to provide advisory eliminate-dups, then a better thing to do
might be to dust off Bernstein's Mail-Followup-To: proposal from http://
cr.yp.to/proto/replyto.html - that's already got *some* MUA traction deployed,
and I know of several other MUAs that don't support it mostly because it was
never progressed down the RFC path.

--==_Exmh_-1714315538P
Content-Type: application/pgp-signature

--==_Exmh_-1714315538P--

Date: Mon, 12 Apr 2004 14:11:34 -0400
From: Keith Moore <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-arun-ncc-smtp-01.txt
Sender: [email-masked]

> > I condsider it completely unacceptable to expect a message header
> > field to modify envelope information, with or without an SMTP
> > extension.
> 
> I agree, except I wouldn't phrase it this way. What's unacceptable is
> for active envelope information to appear in the header. As a
> practical matter, header information is used to create or modify
> envelope information all the time: This is precisely what an MUA does
> when composing a reply.

When an MUA composes a reply, it's creating a new envelope rather
than modifying an existing one of a message in transit.  That and the
sender of that reply gets to decide whether or not each of those
addresses actually  belong in the envelope of that reply.

> This makes me wonder if a modified version of this proposal would be
> acceptable. Suppose the applicability of ncc was limited to list
> processors. We've long argued that list procesors operate at the MUA
> level and not at the MTA level. A mechanism that provides information
> to a list processor(specifically, it tells it to exclude certain
> addresses from the expansion) could legtimately be done with a header.

Yes, it could be done that way without a layer violation, and there's
certainly nothing to stop a list from recognizing an Ncc field and 
interpreting it however it wishes.  However it still doesn't strike
me as something that is generally desirable.

> > More generally, I'm not sure that this is desirable in general.  If
> > a particular list wants to provide people with an option to mail to
> > the list while still excluding some people (and I have occasionally
> > seen a need to do this) then perhaps the list could provide a web
> > interface for that rare purpose.  I don't think it's worth defining
> > an SMTP extension.
> 
> The real question here is what this mechanism is intended to be used
> for. (The draft really doesn't say.) If the intent is to provide a
> security mechanism where specific people are reliably prevented from
> receiving mail as well as being prevented from seeing that they were
> excluded, then an SMTP extension is the only way to do it and the
> chances of deployment are negligable.

I don't even think you can do that with an SMTP extension.  At each
hop that the message traverses there is an opportunity for one of the 
addresses to be aliased to a forbidden address, so you need to propogate
the NCC information as far as possible.  But if you do that, you run
the risk of propagating NCC all the way to an SMTP server that is 
controlled by the forbidden recipient, who can then make note of the
NCC request.

> > If, on the other hand, the intent is to provide an advisory mechanism
> to attempt to block unnecessary message copies in some cases

Duplicate message suppression is a complex problem.  If we're going to
try to addresss it, we need a lot more thought before choosing a mechanism.

--
Regime change 2004 - better late than never.

Date: Mon, 12 Apr 2004 10:36:54 -0700 (PDT)
From: [email-masked]
Subject: Re: I-D ACTION:draft-arun-ncc-smtp-01.txt
To: Keith Moore <[email-masked]>
Cc: Arun Sankar <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> I condsider it completely unacceptable to expect a message header field
> to modify envelope information, with or without an SMTP extension.

I agree, except I wouldn't phrase it this way. What's unacceptable is for
active envelope information to appear in the header. As a practical matter,
header information is used to create or modify envelope information all the
time: This is precisely what an MUA does when composing a reply.

This makes me wonder if a modified version of this proposal would be
acceptable. Suppose the applicability of ncc was limited to list processors.
We've long argued that list procesors operate at the MUA level and not at the
MTA level. A mechanism that provides information to a list processor
(specifically, it tells it to exclude certain addresses from the expansion)
could legtimately be done with a header.

The other alternative would be to make this an SMTP extension.

> Furthermore, since alias expansion or forwarding can be done at any point
> in the signal path, I don't see any way of implementing this functionality
> that doesn't present a risk that an excluded recipient can learn that he's
> being excluded.   (I note that there's no security analysis in this document.)

If you do it as an envelope extension you could always require bouncing when
the extension isn't present. But this has the effect of making deployment very
nontrivial.

> More generally, I'm not sure that this is desirable in general.  If a
> particular list wants to provide people with an option to mail to the list
> while still excluding some people (and I have occasionally seen a need to
> do this) then perhaps the list could provide a web interface for that rare
> purpose.  I don't think it's worth defining an SMTP extension.

The real question here is what this mechanism is intended to be used for. (The
draft really doesn't say.) If the intent is to provide a security mechanism
where specific people are reliably prevented from receiving mail as well as
being prevented from seeing that they were excluded, then an SMTP extension is
the only way to do it and the chances of deployment are negligable.

If, on the other hand, the intent is to provide an advisory mechanism to
attempt to block unnecessary message copies in some cases, where it is
understood that the block isn't going to be 100% reliable and where it is
understood that the blocked individual may be aware of the blocking, then a
simple header could be defined. The question then is whether or not such a
mechanism is useful enough to bother. (I have no religion about this personally
- extra copies of messages don't bother me although I realize they bother other
people a lot.)

				Ned

To: Daryl Odnert <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D announcement: When NOT to Bounce Email 
From: [email-masked]
Date: Mon, 12 Apr 2004 13:20:46 -0400
Sender: [email-masked]

--==_Exmh_-2106113956P
Content-Type: text/plain; charset=us-ascii

On Thu, 08 Apr 2004 15:15:53 PDT, Daryl Odnert <[email-masked]>  said:

> I would like to see the language in the first paragraph of section 3
> broadened a little bit to include more than just "messages generated by
> viruses".  Shouldn't this specification allow messages that are virus
> *infected* to be silently dropped, even if the message isn't generated by a
> virus?

A long long time ago in a galaxy far far away, there actually existed viruses
that were piggybacked onto legitimate email, and as a result the "more proper"
thing to do was to let the sender know they had a virus, and pass along a
decontaminated message to the recipient.

The fact that the anti-virus companies are using that historical fact to
justify sending marketing spam^W^Wnotifications for the current generation of
address-scraping viruses and worms shouldn't be allowed to cloud a protocol
specification, unless we're *really* sure that we want said spec clouded up....

--==_Exmh_-2106113956P
Content-Type: application/pgp-signature

--==_Exmh_-2106113956P--

Date: Mon, 12 Apr 2004 11:41:00 -0400
From: Keith Moore <[email-masked]>
To: Arun Sankar <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-arun-ncc-smtp-01.txt
Sender: [email-masked]

I condsider it completely unacceptable to expect a message header field
to modify envelope information, with or without an SMTP extension.

Furthermore, since alias expansion or forwarding can be done at any point 
in the signal path, I don't see any way of implementing this functionality
that doesn't present a risk that an excluded recipient can learn that he's
being excluded.   (I note that there's no security analysis in this document.)

More generally, I'm not sure that this is desirable in general.  If a 
particular list wants to provide people with an option to mail to the list
while still excluding some people (and I have occasionally seen a need to
do this) then perhaps the list could provide a web interface for that rare
purpose.  I don't think it's worth defining an SMTP extension.

> http://www.ietf.org/internet-drafts/draft-arun-ncc-smtp-01.txt

Date: Mon, 12 Apr 2004 20:09:06 +0530
From: Arun Sankar <[email-masked]>
To: Arun Sankar <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-arun-ncc-smtp-01.txt
Sender: [email-masked]

Hi,

Please let me know if you have any comments on this.

Arun Sankar wrote:

>
> Hi,
>
> I submitted a new version of the ncc in the mail-headers.
>
> [email-masked] wrote:
>
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>>
>>
>>     Title        : Ncc in SMTP
>>     Author(s)    : A. Sankar
>>     Filename    : draft-arun-ncc-smtp-01.txt
>>     Pages        : 4
>>     Date        : 2004-3-11
>>     
>> This draft presents a mechanism to simplify one of the cumbersome 
>> aspects of mailing. The basic intention is to minimize
>> the complication when a mail needs to be sent to n - m mail IDs i.e. 
>> send it to a group Id of n and exclude m from the alias [ALIAS] list.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-arun-ncc-smtp-01.txt
>>
>> To remove yourself from the IETF Announcement list, send a message to 
>> ietf-announce-request with the word unsubscribe in the body of the 
>> message.
>>
>> Internet-Drafts are also available by anonymous FTP. Login with the 
>> username
>> "anonymous" and a password of your e-mail address. After logging in,
>> type "cd internet-drafts" and then
>>     "get draft-arun-ncc-smtp-01.txt".
>>
>> A list of Internet-Drafts directories can be found in
>> http://www.ietf.org/shadow.html or 
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>>
>> Internet-Drafts can also be obtained by e-mail.
>>
>> Send a message to:
>>     [email-masked].
>> In the body type:
>>     "FILE /internet-drafts/draft-arun-ncc-smtp-01.txt".
>>     
>> NOTE:    The mail server at ietf.org can return the document in
>>     MIME-encoded form by using the "mpack" utility.  To use this
>>     feature, insert the command "ENCODING mime" before the "FILE"
>>     command.  To decode the response(s), you will need "munpack" or
>>     a MIME-compliant mail reader.  Different MIME-compliant mail readers
>>     exhibit different behavior, especially when dealing with
>>     "multipart" MIME messages (i.e. documents which have been split
>>     up into multiple messages), so check your local documentation on
>>     how to manipulate these messages.
>>        
>>        
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>>  
>>
>
>

-- 
Arun

-------------------------------------------
                             ___.-~"~-,
Imagination is more        .'    `     \
important than            /` _      )  `\
knowledge ..             /`  a)    /     |
                       :`        /      |
                 <`-._|`  .-.  (      /
                  `-. `--'_.'-.;\___/'
               _     /:--`
              ("\   /`/
              `\'\_/`/
                `._.'
-------------------------------------------

Posted-and-Mailed: no
Subject: Re: I-D announcement: When NOT to Bounce Email
From: bz <[email-masked]>
Organization: LSU Chemistry Department
To: [email-masked]
Date: Fri, 9 Apr 2004 02:02:57 -0500
Sender: [email-masked]

Thanks for the comments. 

I am reading them and thinking about what changes need to be made. 

Also, please feel free to suggest different wording when the current words 
are problematic.

-- 
bz

please pardon my infinite ignorance, the set-of-things-I-do-not-know is an 
infinite set.

[email-masked]

From: "Daryl Odnert" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: I-D announcement: When NOT to Bounce Email
Date: Thu, 8 Apr 2004 15:15:53 -0700
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C41DB6.4DBC57B0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Quick comment:

I would like to see the language in the first paragraph of section 3
broadened a little bit to include more than just "messages generated by
viruses".  Shouldn't this specification allow messages that are virus
*infected* to be silently dropped, even if the message isn't generated by a
virus?  What about phishing attack messages and other types of fraudulent
mail?  What about other messages whose content is unquestionably malicious
or deceitful?

Daryl Odnert
Tumbleweed Communications
Redwood City, California

------_=_NextPart_001_01C41DB6.4DBC57B0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2657.73">
<TITLE>RE: I-D announcement: When NOT to Bounce Email</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Quick comment:</FONT>
</P>

<P><FONT SIZE=3D2>I would like to see the language in the first =
paragraph of section 3 broadened a little bit to include more than just =
&quot;messages generated by viruses&quot;.&nbsp; Shouldn't this =
specification allow messages that are virus *infected* to be silently =
dropped, even if the message isn't generated by a virus?&nbsp; What =
about phishing attack messages and other types of fraudulent =
mail?&nbsp; What about other messages whose content is unquestionably =
malicious or deceitful?</FONT></P>

<P><FONT SIZE=3D2>Daryl Odnert</FONT>
<BR><FONT SIZE=3D2>Tumbleweed Communications</FONT>
<BR><FONT SIZE=3D2>Redwood City, California</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C41DB6.4DBC57B0--

Date: Thu, 8 Apr 2004 17:44:52 -0400
From: Keith Moore <[email-masked]>
To: bz <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: I-D announcement: When NOT to Bounce Email
Sender: [email-masked]

quick comments:

1. Title is too broad.  I don't think we want to try to define a complete
   set of criteria for when NOT to bounce email.

2. I think it's a bit of a stretch to say that use of a false return-path 
   'amplifies' an attack, since the message is only bounced if it doesn't
   get to the recipient. 

3. I don't think it's appropriate to recommend what future RFCs should do,
   since conditions will probably change before we get around to revising
   those RFCs.  Something will be done about the lack of authentication 
   in email.  We don't know what it is yet.  But this document is probably 
   a temporary fix rather than something to carve in stone.

4. Section 6 is cute, but I think it would be better to leave it out.

--
Regime change 2004 - better late than never.

Posted-and-Mailed: no
Subject: I-D announcement: When NOT to Bounce Email
From: bz <[email-masked]>
Organization: LSU Chemistry Department
To: [email-masked]
Date: Thu, 8 Apr 2004 14:10:46 -0500
Sender: [email-masked]

ietf-smtp readers,

It was suggested that I write an I-D. It is a very rough, rather informal 
presentation of a not-very-original-idea.  Comments, please.

[quote from 
<http://www.ietf.org/mail-archive/i-d-announce/Current/msg00042.html>]
A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

        Title           : When NOT to Bounce Email
        Author(s)       : R. Zinn
        Filename        : draft-zinn-smtp-bounces-00.txt
        Pages           : 11
        Date            : 2004-4-6
        
SMTP RFCs currently require that a notice message MUST be sent when a
   message will not be delivered, even when the 'reverse-path' is
   forged by a virus. Of necessity, some ISPs are now dropping such
   messages silently. Silent dropping of such messages should be allowed
   and encouraged under certain circumstances.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-zinn-smtp-bounces-00.txt
....
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

<ftp://ftp.ietf.org/internet-drafts/draft-zinn-smtp-bounces-00.txt>
[end quote]

-- 

bz
please pardon my infinite ignorance, the set-of-things-I-do-not-know is an 
infinite set.

[email-masked]

Date: Mon, 05 Apr 2004 11:13:06 -0500
From: "Eric A. Hall" <[email-masked]>
To: [email-masked]
Subject: [Fwd: I-D ACTION:draft-hall-inline-dsn-00.txt]
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------090604020708000908050604
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

The I-D announcement is attached. The model defined is very similar to
LMTP, but differs in a couple of ways that make it more conservative.

Some highlights:

     [...] it has become common practice for different recipients to
     have their own content filters, and a single response code is not
     sufficiently granular to accurately reflect these differences. For
     example, some users may suffer under policy rules which require
     them to refuse email messages that contain certain words, while
     other users may be required to accept all messages regardless of
     content. But since the current SMTP model only allows a single
     response code for any given message, the only legitimate way to
     accommodate these differences is for all messages to be accepted
     so that they can be examined off-line, with one or more failure
     notification messages eventually being returned to the original
     sender whenever a message is rejected. This process introduces a
     significant burden on the recipient server, which must create,
     queue, and transfer each of the notification messages. Simply put,
     it would be much more efficient for the recipient system to be
     able to refuse email messages on a per-recipient basis while the
     transfer session was still active, thus moving the failure
     processing tasks to the sending system.

and

     The 352 response code is used by a server to indicate that the
     mailbox address specified in the associated RCPT TO command
     appears to be valid, but its validity will not be confirmed until
     after the message data has been transferred.

and

     The 353 response code is used by a server to indicate that the
     message data (as transferred with the DATA or BDAT commands, among
     other possibilities) appears to be valid, but that one or more of
     the recipients may refuse the message. When this response code is
     returned, absolute response codes for each of the recipients which
     were earlier acknowledged with a 352 response code during the
     envelope exchange MUST be provided, and must be provided in the
     order in which they were originally accepted. Once all of the
     recipient-specific response codes have been returned, the end of
     the sequence MUST be indicated with a 250 response code. Each of
     these response codes MUST be returned as independent responses
     (one per line, or one per multi-line response, as necessary).

     [...]

     If the entire message was accepted or refused by every recipient,
     the 353 response code and the subordinate responses MAY be
     substituted with a single response code which reflects the global
     outcome. For example, if all of the recipients accepted the email
     message, then a single 250 response code MAY be returned in lieu
     of generating a 353 response code, the per-recipient response
     codes and the final 250 response code.

and

     The following dialog illustrates a transfer that incorporates
     historical response codes as well as the 352 response code (note
     that this example only shows the envelope and data exchange):

        C: MAIL FROM:<[email-masked]> INLINE-DSN
        S: 250 okay
        C: RCPT TO:<[email-masked]>
        S: 250 this recipient accepts all messages
        C: RCPT TO:<[email-masked]>
        S: 352 recipient looks okay but wait for confirmation
        C: RCPT TO:<[email-masked]>
        S: 352 recipient looks okay but wait for confirmation
        C: RCPT TO:<[email-masked]>
        S: 550 this recipient no longer exists

        C: DATA
        S: 354 go ahead
        C: <sends data>
        C: <crlf>.<crlf>
        S: 353 data looks okay but wait for confirmation
        S: 550 5.6.0 <[email-masked]> refuses the content
        S: 250 2.1.5 <[email-masked]> accepts the content
        S: 250 data accepted by some users

     Note that the postmaster and old-user mailboxes were not itemized
     in the deferred responses, since they were not deferred during the
     envelope exchange.

As per earlier discussion, there are several different ways to represent
post-data per-recipient acceptance, and the mechanisms used in the draft
seems to be the most conservative while causing the least interruption of
the existing state machine model and without obfuscating any of the
existing response code syntaxes.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

--------------090604020708000908050604
Content-Type: message/rfc822;
 name="I-D ACTION:draft-hall-inline-dsn-00.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="I-D ACTION:draft-hall-inline-dsn-00.txt"

To: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-hall-inline-dsn-00.txt
Date: Mon, 05 Apr 2004 10:41:52 -0400
Sender: [email-masked]
Reply-To: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: SMTP Service Extension for Inline DSNs
	Author(s)	: E. Hall
	Filename	: draft-hall-inline-dsn-00.txt
	Pages		: 9
	Date		: 2004-4-2
	
This memo describes a mechanism for the negotiation and transfer 
     of per-recipient notification responses in SMTP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hall-inline-dsn-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-hall-inline-dsn-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-hall-inline-dsn-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-hall-inline-dsn-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-hall-inline-dsn-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce

--------------090604020708000908050604--

From: "Hector Santos" <[email-masked]>
To: <[email-masked]>
Subject: Re: deferred RCPT responses
Date: Sun, 4 Apr 2004 21:16:05 -0400
Organization: Santronics Software, Inc
Sender: [email-masked]

> In pursuit of that interest, I've donated my otherwise billable time and
> submitted a draft with a working model, and if there's further interest,
> I'll certainly work on it some more since it's interesting at least.
>
> As of this point, however, all I'm hearing is that the SMTP state machine
> can't handle it. Since that coincides with my original thinking, I'm now
> of the opinion that it should be shelved.
>
> Do you want to see it progress? I haven't heard a proposal for getting
> around the state limits, just reasons why none of them will work, but
> correct me if I'm wrong.

Eric,  to me, this is a low priority item for state machine changes.  If
state machine changes are going to be considered, then you might as well go
all out and cure all other issues that are more important and stressing in
the industry,  i.e., client/server protocol negotiation, authorization, spam
related issues,  throughput issues, etc.

I wouldn't mind seeing a complete SMTP revamp proposal that addresses ALL
the issues, including multiple RCPT responses/mail handling.  In my view,
vendors will look at something that make sense, something that will address
all concerns when  a drastic change ($$$) is begin considered.

-- 
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

Date: Sat, 03 Apr 2004 20:06:40 -0500
From: John C Klensin <[email-masked]>
To: "Eric A. Hall" <[email-masked]>
cc: [email-masked]
Subject: Re: deferred RCPT responses
Sender: [email-masked]

--On Saturday, April 03, 2004 18:29 -0600 "Eric A. Hall"
<[email-masked]> wrote:

> 
> On 4/3/2004 5:56 PM, John C Klensin wrote:
> 
>> In this context, this statement is equivalent to "you have
>> been deliberately wasting our time by expecting the proposal
>> to be taken seriously".
> 
> On the contrary, I worked on it because an interest was
> expressed:
>...

Sorry.  I didn't mean you individually.  I meant to suggest that
going down this path is a waste of everyone's time if your
explanation/ context is correct.  Whether what you have been
doing is time-wasting, constructive, or a more technical, and
topic-oriented rather than individual-oriented, version of
troll-feeding might or might not be an interesting discussion.
But I would encourage you to think about it.

On the other hand, I may have overreacted:  exploring these
ideas to the point that we can determine whether or not they are
feasible and whether or not they are useful is generally
worthwhile, or at least educational.  The important issue, then,
is knowing when to stop.

> Do you want to see it progress? I haven't heard a proposal for
> getting around the state limits, just reasons why none of them
> will work, but correct me if I'm wrong.

My guess, which I tried to say in the previous note but
obviously didn't succeed in being clear enough, is that the
_value_ of this extension isn't sufficient to justify either
attempting to change the state machine or even to justify much
more energy in figuring out how to do that.   I.e., for me, the
answer is "you are not wrong".

But the opinions of others may differ.

    john

Date: Sat, 03 Apr 2004 18:29:17 -0600
From: "Eric A. Hall" <[email-masked]>
To: John C Klensin <[email-masked]>
CC: [email-masked]
Subject: Re: deferred RCPT responses
Sender: [email-masked]

On 4/3/2004 5:56 PM, John C Klensin wrote:

> In this context, this statement is equivalent to "you have been
> deliberately wasting our time by expecting the proposal to be
> taken seriously".

On the contrary, I worked on it because an interest was expressed:

| Message-ID: <[email-masked]>
| From: Claus Assmann <[email-masked]>
| To: [email-masked]
| Date: Sun, 28 Mar 2004 13:06:05 -0800
| Subject: Re: deferred RCPT responses

| This will at least help filtering if the mail is relayed via the
| MTA of the ISP which should be easier to upgrade to support the
| extension.

and:

| Message-Id: <[email-masked]>
| From: [email-masked]
| To: Tony Hansen <[email-masked]>
| Cc: "Eric A. Hall" <[email-masked]>, [email-masked]
| Date: Thu, 01 Apr 2004 12:02:36 -0500
| Subject: Re: deferred RCPT responses

| On the other hand, some of us run legitimate mailing-list servers,
| and see this as useful functionality

In pursuit of that interest, I've donated my otherwise billable time and
submitted a draft with a working model, and if there's further interest,
I'll certainly work on it some more since it's interesting at least.

As of this point, however, all I'm hearing is that the SMTP state machine
can't handle it. Since that coincides with my original thinking, I'm now
of the opinion that it should be shelved.

Do you want to see it progress? I haven't heard a proposal for getting
around the state limits, just reasons why none of them will work, but
correct me if I'm wrong.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

Date: Sat, 03 Apr 2004 19:02:22 -0500
From: John C Klensin <[email-masked]>
To: Keith Moore <[email-masked]>
cc: [email-masked]
Subject: Re: value of deferred RCPT responses?
Sender: [email-masked]

--On Saturday, April 03, 2004 15:09 -0500 Keith Moore
<[email-masked]> wrote:

> I find myself wondering how valuable deferred RCPT responses
> really are.
> 
> Here's why I say that: because of a race condition documented
> in RFC 1047, SMTP servers should try to minimize delay between
> the receipt of CRLF.CRLF to end the message and the sending of
> a reply.  This further implies that servers shouldn't be
> waiting to actually deliver the message to recipients, running
> procmail scripts, etc. before they respond.  Having the
> capability to report separate status for each of several
> recipients doesn't eliminate the race condition.
> 
> SMTP's current design handles two kinds of per-recipient
> errors:
> - those are cheap to test for and can be done with the
> information available at RCPT time
> - those that are expensive to test for or which cannot really
> be tested until after you see the message
> 
> I suppose there is a third kind - those that can be caught
> on-the-fly, while the message is being received, but which due
> to SMTP limitations cannot be reported until after the message
> is received.  Still I have to wonder how many MTAs are going
> to get restructured so that all of the testing for each of the
> recipients is done concurrently while the message is being
> received.  To do this and still minimize the potential for
> races strikes me as a coding nightmare unless you seriously
> constrain what kinds of criteria can be applied on a
> per-recipient basis.

Exactly.  See my previous note.

--On Saturday, April 03, 2004 16:36 -0600 "Eric A. Hall"
<[email-masked]> wrote:

> On 4/3/2004 2:09 PM, Keith Moore wrote:
> 
>> Here's why I say that: because of a race condition documented
>> in RFC  1047, SMTP servers should try to minimize delay
>> between the receipt of  CRLF.CRLF to end the message and the
>> sending of a reply.
> 
> The current draft model deals with this by immediately
> returning a 353 response code (or any other valid response,
> such as 250/550) after the end-of-data sequence.
> 
> Any additional delays that would be incurred from per-user
> inspection of the content would come after that immediate
> response.

Eric, the reason for the "minimize delay" rule isn't "time to
deliver first response" it is "time until the transaction can be
closed out and the queue entry removed.  The RFC 1047 race
condition is somewhat reduced by "first response" because the
sender knows the receiver got the content, but it isn't enough.
If there is even a vague possibility of getting a "4yz recipient
<xxx> is out to lunch, try later" message -- and there certainly
is in your scenario -- then the sender may need to requeue the
message for that recipient, which prevents closing out the
transaction. 

     john

Date: Sat, 03 Apr 2004 18:56:36 -0500
From: John C Klensin <[email-masked]>
To: "Eric A. Hall" <[email-masked]>
cc: [email-masked]
Subject: Re: deferred RCPT responses
Sender: [email-masked]

--On Saturday, April 03, 2004 16:15 -0600 "Eric A. Hall"
<[email-masked]> wrote:

> 
> On 4/3/2004 12:23 PM, John C Klensin wrote:
> 
>> Actually, yes it is, especially given operational experience
>> with clients that won't even accept a multiline response in
>> that situation but are sure that the only possible responses
>> are:
> 
> Why would the client negotiate an extension it couldn't
> handle? Of course, that applies to almost of the potential
> response models, so as far as that goes, any of them will be
> fine if whatever does get chosen is clearly defined and
> requires negotiation--if they all suck then its just a matter
> of which form of suckiness do we want right.

Because, unsurprisingly, the implementation/ deployment pattern
for SMTP extensions is that

	* things that are easy to do and don't upset existing
	logic are more likely to be implemented than those that
	are harder.
	
	* things that are of obvious high value and leverage on
	good service are more likely to be implemented than
	those of small marginal value or low expectations of
	value.

Now, you are talking about making something that is hard (for
the reason above) and of low marginal value (see below).   Even
trying to define such things may be a waste of time, and they
clearly violate Marshall's principle about ubiquitous deployment
(which is part of the standard and part of the criteria for IETF
approval of an extension).

Please try to think about these things from the standpoint of an
implementer and commercial vendor, even if you don't directly
have very much of that experience.

> The thing I like about 353/.../250 is that it leaves the
> intermediary response codes clean and transparent, while all
> of the others result in semantic difficulties ("250-550" is
> confusing as heck, while "250-2.1.5" is non-conformant) or
> break other parts of the model ("250-"/"550-"), and is why I
> used it in the draft last week.

See above.

> At this point the whole thing is mostly an intellectual
> exercise. The best solution is what I pondered in the original
> message--put it off until a replacement service is developed
> that can handle this kind of stuff from the beginning.

In this context, this statement is equivalent to "you have been
deliberately wasting our time by expecting the proposal to be
taken seriously".   Perhaps we need a mailing list, in some
Fantasy tree, for ideas that would be need to have in SMTP if,
e.g, the world was flat.   My apologies for being harsh, but,...

     john

Date: Sat, 03 Apr 2004 16:36:07 -0600
From: "Eric A. Hall" <[email-masked]>
To: [email-masked]
Subject: Re: value of deferred RCPT responses?
Sender: [email-masked]

On 4/3/2004 2:09 PM, Keith Moore wrote:

> Here's why I say that: because of a race condition documented in RFC 
> 1047, SMTP servers should try to minimize delay between the receipt of 
> CRLF.CRLF to end the message and the sending of a reply.

The current draft model deals with this by immediately returning a 353
response code (or any other valid response, such as 250/550) after the
end-of-data sequence.

Any additional delays that would be incurred from per-user inspection of
the content would come after that immediate response.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

Date: Sat, 03 Apr 2004 16:15:55 -0600
From: "Eric A. Hall" <[email-masked]>
To: John C Klensin <[email-masked]>
CC: [email-masked]
Subject: Re: deferred RCPT responses
Sender: [email-masked]

On 4/3/2004 12:23 PM, John C Klensin wrote:

> Actually, yes it is, especially given operational experience
> with clients that won't even accept a multiline response in that
> situation but are sure that the only possible responses are:

Why would the client negotiate an extension it couldn't handle? Of course,
that applies to almost of the potential response models, so as far as that
goes, any of them will be fine if whatever does get chosen is clearly
defined and requires negotiation--if they all suck then its just a matter
of which form of suckiness do we want right.

The thing I like about 353/.../250 is that it leaves the intermediary
response codes clean and transparent, while all of the others result in
semantic difficulties ("250-550" is confusing as heck, while "250-2.1.5"
is non-conformant) or break other parts of the model ("250-"/"550-"), and
is why I used it in the draft last week.

At this point the whole thing is mostly an intellectual exercise. The best
solution is what I pondered in the original message--put it off until a
replacement service is developed that can handle this kind of stuff from
the beginning.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

Cc: Keith Moore <[email-masked]>
From: Keith Moore <[email-masked]>
Subject: value of deferred RCPT responses?
Date: Sat, 3 Apr 2004 15:09:24 -0500
To: [email-masked]
Sender: [email-masked]

I find myself wondering how valuable deferred RCPT responses really are.

Here's why I say that: because of a race condition documented in RFC 
1047, SMTP servers should try to minimize delay between the receipt of 
CRLF.CRLF to end the message and the sending of a reply.  This further 
implies that servers shouldn't be waiting to actually deliver the 
message to recipients, running procmail scripts, etc. before they 
respond.  Having the capability to report separate status for each of 
several recipients doesn't eliminate the race condition.

SMTP's current design handles two kinds of per-recipient errors:
- those are cheap to test for and can be done with the information 
available at RCPT time
- those that are expensive to test for or which cannot really be tested 
until after you see the message

I suppose there is a third kind - those that can be caught on-the-fly, 
while the message is being received, but which due to SMTP limitations 
cannot be reported until after the message is received.  Still I have 
to wonder how many MTAs are going to get restructured so that all of 
the testing for each of the recipients is done concurrently while the 
message is being received.  To do this and still minimize the potential 
for races strikes me as a coding nightmare unless you seriously 
constrain what kinds of criteria can be applied on a per-recipient 
basis.

Keith

Date: Sat, 03 Apr 2004 13:23:47 -0500
From: John C Klensin <[email-masked]>
To: "Eric A. Hall" <[email-masked]>
cc: [email-masked]
Subject: Re: deferred RCPT responses
Sender: [email-masked]

--On Thursday, April 01, 2004 18:22 -0600 "Eric A. Hall"
<[email-masked]> wrote:

>... 
> I would rather use the proposed surrounder pair as
> demonstrated above (353/.../250, with per-RCPT responses in
> between). That isn't radically different from the asymmetrical
> stuff we see with pipelining or auth.

Actually, yes it is, especially given operational experience
with clients that won't even accept a multiline response in that
situation but are sure that the only possible responses are:

	* (250) Data accepted.
	
	* (anything else) Transmission/receipt failure, please
	requeue mail.

     john

Date: Thu, 01 Apr 2004 18:22:17 -0600
From: "Eric A. Hall" <[email-masked]>
To: John C Klensin <[email-masked]>
CC: [email-masked]
Subject: Re: deferred RCPT responses
Sender: [email-masked]

On 4/1/2004 5:00 PM, John C Klensin wrote:

> * Using a "defer" code that is unique to this, not 350

I've currently got 352 for the user-looks-okay-but-check-after-data and
353 for the data-looks-okay-but-check-the-deferred-users

> * Specifying the format of the defer message, possibly including
> a sequence number in it that can be repeated in the later
> (deferred) responses -- parsing things in order to determine
> what was valid or invalid has often been problematic.

The way I'm working this is that a response has to be returned for every
RCPT that returned 352 and they have to be provided in the same order. The
mailbox address strings are for extra safeness.

> * Think carefully about the implications of 
> 
>      RCPT TO:<victim> Strange-recipient-dependent-option=foo

yah that's what I'm going through now

> * I have no idea what you intend by "350 content smells ok" and
> what its role is -- you haven't seen content yet, unless I
> misunderstand the proposal.

That 350 was for after the end-of-data marker. This might be clearer:

  C: RCPT TO:<sucker>
  S: 352 user looks okay but check after data
  C: RCPT TO:<hardass>
  S: 352 user looks okay but check after data

  C: DATA
  S: 354
  C: <CRLF>.<CRLF>
  S: 353 data looks okay but check users

  S: 250 <sucker> accepts the mail
  S: 550 <hardass> refuses the mail

  S: 250 data accepted for some users

Putting your concerns in that model, is that the post-data block might
ought to be multiline:

  C: <CRLF>.<CRLF>
  S: 353-data looks okay but check users
  S: 250-<sucker> accepts the mail
  S: 550-<hardass> refuses the mail
  S: 250 data accepted for some users

The problem I have with using different codes on the different lines is
the same one you raised: I'm positive there are implementations that
expect all of the lines to be the same and which read the first line
assuming as much.

I would rather use the proposed surrounder pair as demonstrated above
(353/.../250, with per-RCPT responses in between). That isn't radically
different from the asymmetrical stuff we see with pipelining or auth.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

Date: Thu, 01 Apr 2004 18:00:35 -0500
From: John C Klensin <[email-masked]>
To: "Eric A. Hall" <[email-masked]>, [email-masked]
Subject: Re: deferred RCPT responses
Sender: [email-masked]

Eric,

This looks plausible, but the devil is, as usual, in the
details.  In addition to suggestions made by others, please
consider:

* Using a "defer" code that is unique to this, not 350

* Specifying the format of the defer message, possibly including
a sequence number in it that can be repeated in the later
(deferred) responses -- parsing things in order to determine
what was valid or invalid has often been problematic.

* Think carefully about the implications of 

     RCPT TO:<victim> Strange-recipient-dependent-option=foo

in a situation in which responses are deferred, but that option
turns out to be invalid for the user.  I.e., there may be a
whole range of response codes, etc., here and some cases might
not be covered by your outline.  Requiring extended status codes
along with this might be a good idea.

* I think you are going to want an intermediate reply model for
DATA that is more consistent with current practice, i.e.,

       C: DATA
       S: [...]
       S: 354 Go ahead and send message body

or
       C: DATA
       S: [...]
       S: 5yz No valid recipients- do not send content

and _no_ other codes at the end of the sequence.

* I have no idea what you intend by "350 content smells ok" and
what its role is -- you haven't seen content yet, unless I
misunderstand the proposal.   If I were the server designer, I'd
want to be able to either evaluate the addresses before
accepting content or to get the content and then evaluate and I
suggest your proposal reflect that (with a
"will-accept-data-before-verifying-addresses" parameter to MAIL
FROM...INSTANT-DSN if needed.

* And (this is the important one)...

	>  C: DATA [...]
	>  S: 350 content smells okay
	>  S: 550 <hardass> does not like this content
	>  S: 452 <sucker> insufficient quota space
	>  S: 250 content accepted for some recipients

is pretty close to a non-starter, since it breaks the "one
command, one response" model of SMTP.  You would need

	C: DATA [...]
	S: 550-<hardass> does not like this content
	S: 452-<sucker> insufficient quota space
	S: 354 Some recipients are valid, send data
    C: blah blah blah
    C: blah blah blah
    C: .
    S: 250 Content accepted
or
    S: 5yz-Please take virus-laden content and put 
    S: 5yz in honorable ear.

Unfortunately, that model raises a different issue -- it is
unclear that most clients will bother looking at reply codes
after the first one in a multiline reply, expecting that all of
them will be the same.  So the extension proposal would need to
explicitly require that per-line checking/evaluation.

If one defers the address verification until after content is
accepted, the above gets rearranged, but the same issues about
continuation versus separate replies applies.

     john

--On Thursday, April 01, 2004 09:17 -0600 "Eric A. Hall"
<[email-masked]> wrote:

> Specifically, I'm suggesting that we provide a mechanism
> where per-recipient ACKs are *allowed* but servers can
> continue to accept/reject globally as well. Messages that are
> universally good or universally bad can still use a global
> 2xx/5xx after the end-of-data, while mixed success can be
> responded to on a per-recipient basis.
> 
> An example:
> 
>  C: EHLO foobar
>  S: 250 INSTANT-DSN
> 
>  C: MAIL FROM:<malware> INSTANT-DSN
>  S: 250
>  C: RCPT TO:<hardass>
>  S: 350 will defer
>  C: RCPT TO:<sucker>
>  S: 350 will defer
>  C: RCPT TO:<postmaster>   # <---- notice
>  S: 250 always accepts     # <---- notice
> 
>  C: DATA [...]
>  S: 550 message contains a virus; unacceptable for all
> recipients
> 
> or
> 
>  C: DATA [...]
>  S: 250 content accepted for all recipients
> 
> That is basically the same as things work now; the only
> difference is the deferred RCPT confirmations, and the
> confirmations are unnecessary since the content was globally
> accepted/rejected.
> 
> An example of the deferred responses for the deferred
> recipients:
> 
>  C: DATA [...]
>  S: 350 content smells okay
>  S: 550 <hardass> does not like this content
>  S: 452 <sucker> insufficient quota space
>  S: 250 content accepted for some recipients
> 
> <postmaster> accepted earlier so no reason to respond

To: Tony Hansen <[email-masked]>
Cc: "Eric A. Hall" <[email-masked]>, [email-masked]
Subject: Re: deferred RCPT responses 
From: [email-masked]
Date: Thu, 01 Apr 2004 12:02:36 -0500
Sender: [email-masked]

--==_Exmh_1394711348P
Content-Type: text/plain; charset=us-ascii

On Thu, 01 Apr 2004 11:28:06 EST, Tony Hansen said:
> I have no problem with this proposal, per se. However, I don't think it will 
> help with the spam problem much because I doubt that the illegit spammers will 
> be using an MTA that supports this option.

On the other hand, some of us run legitimate mailing-list servers, and see this
as useful functionality - despite our best efforts, not all postings are
acceptable to all recipients, and anything I can do to make it easier for the
remote end to tell me in more detail, and more quickly, exactly what went
wrong, the easier *my* job gets.  "Some undetermined number of RCTP TO's bounced"
in a separate bounce message sucks.  Being told which one is better.  Being
able to find out which one, and why, while I've still got the connection open,
is even better still.

Eric:  can you make sure your proposal is PIPELINE-friendly? There's sites that
we send enough RCTP TO: in one message that it makes a big difference...

--==_Exmh_1394711348P
Content-Type: application/pgp-signature

--==_Exmh_1394711348P--

Date: Thu, 01 Apr 2004 11:28:06 -0500
From: Tony Hansen <[email-masked]>
To: "Eric A. Hall" <[email-masked]>
CC: [email-masked]
Subject: Re: deferred RCPT responses
Sender: [email-masked]

I have no problem with this proposal, per se. However, I don't think it will 
help with the spam problem much because I doubt that the illegit spammers will 
be using an MTA that supports this option.

	Tony

Eric A. Hall wrote:

> 
> After some thinking on this, I believe that an adaptation of the LMTP
> approach is going to provide the most bang with the least breakage. This
> means providing all of the RCPT addresses before the DATA exchange, and
> then allowing for per-recipient confirmation after the DATA sequence. This
> guarantees that spamtrap addresses work properly, that extensions like
> quota are trapped properly, etc., and also preserves the existing state
> machinery pretty closely, in that the envelope exchange can "complete"
> before data, with the confirmation responses simply being treated as
> in-line DSNs.
> 
> Focusing exclusively on an "in-line DSN" capability allows for a smaller
> protocol machine, and is somewhat different from the deferred RCPT model
> used in LMTP. Specifically, I'm suggesting that we provide a mechanism
> where per-recipient ACKs are *allowed* but servers can continue to
> accept/reject globally as well. Messages that are universally good or
> universally bad can still use a global 2xx/5xx after the end-of-data,
> while mixed success can be responded to on a per-recipient basis.
> 
> An example:
> 
>  C: EHLO foobar
>  S: 250 INSTANT-DSN
> 
>  C: MAIL FROM:<malware> INSTANT-DSN
>  S: 250
>  C: RCPT TO:<hardass>
>  S: 350 will defer
>  C: RCPT TO:<sucker>
>  S: 350 will defer
>  C: RCPT TO:<postmaster>   # <---- notice
>  S: 250 always accepts     # <---- notice
> 
>  C: DATA [...]
>  S: 550 message contains a virus; unacceptable for all recipients
> 
> or
> 
>  C: DATA [...]
>  S: 250 content accepted for all recipients
> 
> That is basically the same as things work now; the only difference is the
> deferred RCPT confirmations, and the confirmations are unnecessary since
> the content was globally accepted/rejected.
> 
> An example of the deferred responses for the deferred recipients:
> 
>  C: DATA [...]
>  S: 350 content smells okay
>  S: 550 <hardass> does not like this content
>  S: 452 <sucker> insufficient quota space
>  S: 250 content accepted for some recipients
> 
> <postmaster> accepted earlier so no reason to respond
> 
> Another option allowed by this model:
> 
>  C: MAIL FROM:<malware> INSTANT-DSN
>  S: 250
>  C: RCPT TO:<hardass>
>  S: 350 will defer
>  C: RCPT TO:<spamtrap>     # <---- notice
>  S: 550 always rejects     # <---- notice
>  C: RCPT TO:<sucker>
>  S: 550 refuses            # <---- now rejects
>  C: RCPT TO:<postmaster>
>  S: 550 refuses            # <---- now rejects
> 
>  C: DATA [...]
>  S: 550 message addresses spamtrap; universally refused
> 
> So it seems that this model is the most flexible, preserves the existing
> state machinery and extension model, but also provides for per-recipient
> acceptance and rejections.
> 
> I can write this up pretty quickly (need to figure out a couple of other
> small issues first) but otherwise, anybody see any problems with this?
> 
> Thanks
> 

Date: Thu, 01 Apr 2004 09:17:49 -0600
From: "Eric A. Hall" <[email-masked]>
To: [email-masked]
Subject: Re: deferred RCPT responses
Sender: [email-masked]

After some thinking on this, I believe that an adaptation of the LMTP
approach is going to provide the most bang with the least breakage. This
means providing all of the RCPT addresses before the DATA exchange, and
then allowing for per-recipient confirmation after the DATA sequence. This
guarantees that spamtrap addresses work properly, that extensions like
quota are trapped properly, etc., and also preserves the existing state
machinery pretty closely, in that the envelope exchange can "complete"
before data, with the confirmation responses simply being treated as
in-line DSNs.

Focusing exclusively on an "in-line DSN" capability allows for a smaller
protocol machine, and is somewhat different from the deferred RCPT model
used in LMTP. Specifically, I'm suggesting that we provide a mechanism
where per-recipient ACKs are *allowed* but servers can continue to
accept/reject globally as well. Messages that are universally good or
universally bad can still use a global 2xx/5xx after the end-of-data,
while mixed success can be responded to on a per-recipient basis.

An example:

 C: EHLO foobar
 S: 250 INSTANT-DSN

 C: MAIL FROM:<malware> INSTANT-DSN
 S: 250
 C: RCPT TO:<hardass>
 S: 350 will defer
 C: RCPT TO:<sucker>
 S: 350 will defer
 C: RCPT TO:<postmaster>   # <---- notice
 S: 250 always accepts     # <---- notice

 C: DATA [...]
 S: 550 message contains a virus; unacceptable for all recipients

or

 C: DATA [...]
 S: 250 content accepted for all recipients

That is basically the same as things work now; the only difference is the
deferred RCPT confirmations, and the confirmations are unnecessary since
the content was globally accepted/rejected.

An example of the deferred responses for the deferred recipients:

 C: DATA [...]
 S: 350 content smells okay
 S: 550 <hardass> does not like this content
 S: 452 <sucker> insufficient quota space
 S: 250 content accepted for some recipients

<postmaster> accepted earlier so no reason to respond

Another option allowed by this model:

 C: MAIL FROM:<malware> INSTANT-DSN
 S: 250
 C: RCPT TO:<hardass>
 S: 350 will defer
 C: RCPT TO:<spamtrap>     # <---- notice
 S: 550 always rejects     # <---- notice
 C: RCPT TO:<sucker>
 S: 550 refuses            # <---- now rejects
 C: RCPT TO:<postmaster>
 S: 550 refuses            # <---- now rejects

 C: DATA [...]
 S: 550 message addresses spamtrap; universally refused

So it seems that this model is the most flexible, preserves the existing
state machinery and extension model, but also provides for per-recipient
acceptance and rejections.

I can write this up pretty quickly (need to figure out a couple of other
small issues first) but otherwise, anybody see any problems with this?

Thanks

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/