[Asrg] where the message originated

[Rich Kulawiec]

On Wed, Jan 14, 2009 at 01:00:32PM +0000, David Wilson wrote:
> The error here is to assume that you get the message from the
> originating system. There are scenarios in which you get the message
> from an innocent (perhaps in more than one sense of the word)
> *intermediate* MTA. It is the reaction of such an MTA to a rejection
> which is the problem.

That's not an assumption, it's a fact. If 1.2.3.4 connects to my MX's
and attempts delivery, then 1.2.3.4 IS the originating system, as far
as my MX is concerned.

Now the message may -- or may not -- have *really* originated on 1.2.3.4,
but that's of course quite impossible to know.  (I trust everyone is aware
that malware routinely adds fake headers, so anything it claims about
itself, including its putative origin, shouldn't be believed.  The only
things you can know about it are things that you independently determine.)

> An intermediate MTA is not be a open relay, because relaying is often
> defined in terms of the system from which the message arrives. For
> instance, a company has a "boundary" MTA. A PC within the company's
> network is compromised (the user accessed an unsuitable web site in
> their lunch break). The trojan sends messages via the boundary MTA.
> Unless that MTA checks the return-path address, and the boundary MTA
> picks up on the virus, then the rejection by the next hop MTA is a
> problem.

So we are to presume that malware which has taken over user U's PC,
and thus is likely already in full control of everything it does,
is going to send a copy of itself through the outbound MTA on that
network, with the goal that it will be rejected by someone's MX,
so that the MTA will generate an NDR and send it back to user U...
who is already infected?  What, exactly, is the point?

Or that this same malware, having rummaged through user U's inbox and
outbox and other files resident on the disk drives on U's PC, has
now decided to attempt delivery to co-workers V, W, and X, and rather
than just attaching itself to the next outbound messages from X to
any of them, or crafting a plausible forgery and sending it now,
will instead try to forge V/W/X's addresses as the putative sender,
submit it to the outbound MTA, and hope that something rejects it
so that the local MTA will send an NDR with it to V/W/X?

We've wandered into fantasyland here.  Why should such elaborate tricks
be used when there are a large number of much easier, eminently successful
tactics to try?  After all, if the MTA doesn't know how to detect this
particular bit of malware when it's headed to an external destination,
then it seems unlikely it'll detect it when it's headed to an internal one.
The simplest course is for it to just send itself directly -- or, even
better, to infest the system running the MTA, which makes further
propagation considerably simpler.

> After all, if the "MTA" from which you received the infected message is
> not innocent, perhaps not even a proper MTA, then rejecting the message
> is also pointless. The rejection will be ignored, and so the overall
> effect will be the same as if it were accepted and discarded.

*If* it's not a proper MTA, yes.  But you have no way to know that,
nor can you be certain that you're not making a classification error,
so best practice remains to use the SMTP protocol to indicate
rejection.  If it does turn out to be a proper MTA and/or if it does
turn out you've made an error, you've given everyone a decent chance
of noting it, tracking it, and fixing it.

---Rsk