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 <moore(_at_)cs(_dot_)utk(_dot_)edu>
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 <moore(_at_)cs(_dot_)utk(_dot_)edu>
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" <daryl(_dot_)odnert(_at_)tumbleweed(_dot_)com>
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 <wayne(_at_)midwestcs(_dot_)com>
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. (LarrySheldon(_at_)cox(_dot_)net)
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 (jfh(_at_)avondale(_dot_)demon(_dot_)co(_dot_)uk)
Subject: Re: Cox-clueless
Newsgroups: news.admin.net-abuse.email
Date: 2004-04-10 16:33:24 PST
bz <bz+nanae(_at_)ch100-5(_dot_)chem(_dot_)lsu(_dot_)edu> 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. (LarrySheldon(_at_)cox(_dot_)net)
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 (pressedpork(_dot_)animal(_dot_)spamtrap(_at_)myrealbox(_dot_)com)
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."
<LarrySheldon(_at_)cox(_dot_)net> 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 (jfh(_at_)avondale(_dot_)demon(_dot_)co(_dot_)uk)
Subject: Re: Cox-clueless
Newsgroups: news.admin.net-abuse.email
Date: 2004-04-11 07:08:53 PST
Laurence F. Sheldon, Jr. <LarrySheldon(_at_)cox(_dot_)net> 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. (LarrySheldon(_at_)cox(_dot_)net)
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. (LarrySheldon(_at_)cox(_dot_)net)
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 (dan_oetting(_at_)qwest(_dot_)net)
Subject: Re: Cox-clueless
Newsgroups: news.admin.net-abuse.email
Date: 2004-04-12 09:09:55 PST
bz <bz+nanae(_at_)ch100-5(_dot_)chem(_dot_)lsu(_dot_)edu> wrote:
"Laurence F. Sheldon, Jr." <LarrySheldon(_at_)cox(_dot_)net> 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. (LarrySheldon(_at_)cox(_dot_)net)
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 (dan_oetting(_at_)qwest(_dot_)net)
Subject: Re: Cox-clueless
Newsgroups: news.admin.net-abuse.email
Date: 2004-04-12 11:04:34 PST
"Laurence F. Sheldon, Jr." <LarrySheldon(_at_)cox(_dot_)net> 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. (LarrySheldon(_at_)cox(_dot_)net)
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 (hmurray(_at_)suespammers(_dot_)org)
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 (MorelyDotes(_at_)spamblocked(_dot_)com)
Subject: Re: Cox-clueless
Newsgroups: news.admin.net-abuse.email
Date: 2004-04-13 09:20:21 PST
bz <bz+nanae(_at_)ch100-5(_dot_)chem(_dot_)lsu(_dot_)edu> 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 (jfh(_at_)avondale(_dot_)demon(_dot_)co(_dot_)uk)
Subject: Re: Cox-clueless
Newsgroups: news.admin.net-abuse.email
Date: 2004-04-12 05:50:12 PST
Laurence F. Sheldon, Jr. <LarrySheldon(_at_)cox(_dot_)net> 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. (LarrySheldon(_at_)cox(_dot_)net)
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(_dot_)13282$wb4(_dot_)12165(_at_)okepread02>,
Laurence F. Sheldon, Jr. <LarrySheldon(_at_)cox(_dot_)net> 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 (bonomi(_at_)host122(_dot_)r-bonomi(_dot_)com)
Subject: Re: Cox-clueless
Newsgroups: news.admin.net-abuse.email
Date: 2004-04-10 11:56:21 PST
bz <bz+nanae(_at_)ch100-5(_dot_)chem(_dot_)lsu(_dot_)edu> wrote:
Satch <usenet(_at_)satchell(_dot_)net> 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 (hmurray(_at_)suespammers(_dot_)org) 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(_at_)somewhere sends a messages to addressee(_at_)M
Mail from somewhere --> M --> F
Mail for addressee(_at_)M actually goes to addressee(_at_)F
Everything is fine until F refuses a message. Things are still fine as
long as originator(_at_)somewhere is the actual sender. When a virus forges
originator(_at_)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 (invalid(_at_)earthlink(_dot_)net(_dot_)invalid)
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 (morelydotes(_at_)spamblocked(_dot_)com)
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
<invalid(_at_)earthlink(_dot_)net(_dot_)invalid> 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 (vjs(_at_)calcite(_dot_)rhyolite(_dot_)com)
Subject: Re: Cox-clueless
Newsgroups: news.admin.net-abuse.email
Date: 2004-04-09 07:18:14 PST
In article
<Mhrdc(_dot_)1984$zj3(_dot_)121(_at_)newsread3(_dot_)news(_dot_)atl(_dot_)earthlink(_dot_)net>,
Someone Else <invalid(_at_)earthlink(_dot_)net(_dot_)invalid> 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 (vjs(_at_)calcite(_dot_)rhyolite(_dot_)com)
Subject: Re: Cox-clueless
Newsgroups: news.admin.net-abuse.email
Date: 2004-04-10 06:03:17 PST
Someone Else <invalid(_at_)earthlink(_dot_)net(_dot_)invalid> 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 (invalid(_at_)earthlink(_dot_)net(_dot_)invalid)
Subject: Re: Cox-clueless
Newsgroups: news.admin.net-abuse.email
Date: 2004-04-10 13:12:31 PST
Vernon Schryver wrote:
In article
<SxOdc(_dot_)3032$zj3(_dot_)918(_at_)newsread3(_dot_)news(_dot_)atl(_dot_)earthlink(_dot_)net>,
Someone Else <invalid(_at_)earthlink(_dot_)net(_dot_)invalid> 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 vjs(_at_)rhyolite(_dot_)com
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 (vjs(_at_)calcite(_dot_)rhyolite(_dot_)com)
Subject: Re: Cox-clueless
Newsgroups: news.admin.net-abuse.email
Date: 2004-04-10 14:17:25 PST
Someone Else <invalid(_at_)earthlink(_dot_)net(_dot_)invalid> 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 (invalid(_at_)earthlink(_dot_)net(_dot_)invalid)
Subject: Re: Cox-clueless
Newsgroups: news.admin.net-abuse.email
Date: 2004-04-11 03:27:17 PST
Vernon Schryver wrote:
In article
<OyYdc(_dot_)2984$l75(_dot_)1448(_at_)newsread2(_dot_)news(_dot_)atl(_dot_)earthlink(_dot_)net>,
Someone Else <invalid(_at_)earthlink(_dot_)net(_dot_)invalid> 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 (vjs(_at_)calcite(_dot_)rhyolite(_dot_)com)
Subject: Re: Cox-clueless
Newsgroups: news.admin.net-abuse.email
Date: 2004-04-11 11:00:27 PST
Someone Else <invalid(_at_)earthlink(_dot_)net(_dot_)invalid> 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 (morelydotes(_at_)spamblocked(_dot_)com)
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
<invalid(_at_)earthlink(_dot_)net(_dot_)invalid> 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 (af380(_at_)chebucto(_dot_)ns(_dot_)ca)
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 (invalid(_at_)earthlink(_dot_)net(_dot_)invalid)
Subject: Re: Cox-clueless
Newsgroups: news.admin.net-abuse.email
Date: 2004-04-10 01:59:43 PST
John Doherty wrote:
In article
<Mhrdc(_dot_)1984$zj3(_dot_)121(_at_)newsread3(_dot_)news(_dot_)atl(_dot_)earthlink(_dot_)net>,
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:
<SxOdc(_dot_)3032$zj3(_dot_)918(_at_)newsread3(_dot_)news(_dot_)atl(_dot_)earthlink(_dot_)net>)
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 (invalid(_at_)earthlink(_dot_)net(_dot_)invalid)
Subject: Re: Cox-clueless
Newsgroups: news.admin.net-abuse.email
Date: 2004-04-10 13:18:34 PST
John Doherty wrote:
In article
<3IOdc(_dot_)3034$zj3(_dot_)1067(_at_)newsread3(_dot_)news(_dot_)atl(_dot_)earthlink(_dot_)net>,
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 (invalid(_at_)earthlink(_dot_)net(_dot_)invalid)
Subject: Re: Cox-clueless
Newsgroups: news.admin.net-abuse.email
Date: 2004-04-10 19:54:55 PST
John Doherty wrote:
In article
<uEYdc(_dot_)2988$l75(_dot_)2087(_at_)newsread2(_dot_)news(_dot_)atl(_dot_)earthlink(_dot_)net>,
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
(usenetjunk2004(_at_)yahoo(_dot_)com) Subject: Re: Cox-clueless
Newsgroups: news.admin.net-abuse.email
Date: 2004-04-08 19:40:21 PST
"Scott Wertz" <nobody(_at_)example(_dot_)com> 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 (buss_error(_at_)yahoo(_dot_)com)
Subject: Re: Cox-clueless
Newsgroups: news.admin.net-abuse.email
Date: 2004-04-08 22:49:44 PST
"Jay Stuler" <usenetjunk2004(_at_)yahoo(_dot_)com> 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 (spamtrap(_at_)cricalix(_dot_)net) 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 (TonyRoza(_at_)hotmail(_dot_)com)
Subject: Re: Cox-clueless
Newsgroups: news.admin.net-abuse.email
Date: 2004-04-08 22:58:05 PST
"fudo" <fudo(_at_)spamblocked(_dot_)invalid> wrote in message:
In article
<Xns94C5D8447F627morelydotespcgamerev(_at_)192(_dot_)168(_dot_)0(_dot_)197>,
"Morely 'I drank what?' Dotes" <morelydotes(_at_)spamblocked(_dot_)com> 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 (jfh(_at_)avondale(_dot_)demon(_dot_)co(_dot_)uk) Subject:
Re: Cox-clueless
Newsgroups: news.admin.net-abuse.email
Date: 2004-04-10 04:34:40 PST
In article
<Xns94C6622BAF2E0MorelyDotesspamblock(_at_)216(_dot_)99(_dot_)211(_dot_)247>,
Morely 'spam is theft' Dotes <MorelyDotes(_at_)spamblocked(_dot_)com> wrote:
bz <bz+nanae(_at_)ch100-5(_dot_)chem(_dot_)lsu(_dot_)edu> wrote:
Uncle StoatWarbler
<alanb+google5(_at_)google5(_dot_)manawatu(_dot_)net(_dot_)nz>:
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.