[Changing the subject - btw, is there a list of the recommended subject
prefixes somewhere? For those of us who post rather infrequently to this
list it would be handy]
On 1970-01-01 03:50:53 -0500, Jim Witte wrote:
I have in the past gotten an awful lot of "Mail undeliverable"
message from the daemon, with attached virus code in raw hex. I have
been told that some of the worms will send out email that looks like
such a mail daemon error. This could be, but I got the impression here
that some worm had sent out copies of itself to a bunch of addresses,
with my address in a spoofed From: header, and that for those addresses
that had been cancelled, or did not exist (I've noticed that many
worms/spammers appear to send junk to several "variants" of a
particular address). Then the mail (ALL of it, including the attached
worm code in raw hex) is bounced back to me (the spoofed sender).
Ignoring the question what "raw hex" might be and the fact that there
are worms which disguise themselves as DSNs, yes, real bounced viruses
and spam are annoying enough.
Does anyone else think this makes sense and that the RFC for mailer
daemons should therefore be changed (or a new RFC proposed, or however
the process goes, I'm new to this, as you can tell..)
There is no need to change an RFC, since, AFAICS, no RFC says that the
complete message must be included in the bounce message:
RFC 2821:
If an SMTP server has accepted the task of relaying the mail and
later finds that the destination is incorrect or that the mail cannot
be delivered for some other reason, then it MUST construct an
"undeliverable mail" notification message and send it to the
originator of the undeliverable mail (as indicated by the reverse-
path). Formats specified for non-delivery reports by other standards
(see, for example, [24, 25]) SHOULD be used if possible.
RFC 3464:
(d) If the original message or a portion of the message is to be
returned to the sender, it appears as the third component of the
multipart/report.
So RFC 2821 only mandates that some non-delivery notification must be
sent, but does not the information included in or the format. Even the
totally useless bounce I got recently "The message sent from <undisclosed>
to <undisclosed> could not be delivered" is conforming to RFC 2821. It
does however strongly recommend the format in RFC 3464
(multipart/report), which includes *the original message or a portion* of
it as an *optional* part.
So an MTA conforming to both RFCs could (and probably should) only
return a part (maybe the first text/plain part) of the original message.
However, RFC 3464 also says:
(e) It must preserve enough information to allow the maintainer of a
remote MTA to understand (and if possible, reproduce) the
conditions that caused a delivery failure at that MTA.
and the third part should be of type message/rfc822 (though the RFC
doesn't explicitely say so), so some care must be taken when shortening
messages.
Your "raw hex" bounces almost certainly do not conform to RFC 3464, btw.
hp
--
_ | Peter J. Holzer | In this vale
|_|_) | Sysadmin WSR | Of toil and sin
| | | hjp(_at_)hjp(_dot_)at | Your head grows bald
__/ | http://www.hjp.at/ | But not your chin. -- Burma Shave
pgpO8Tl8T1fnP.pgp
Description: PGP signature