Re: [Asrg] where the message originated

> Ah, gotcha.  I agree that silently swallowing the message might have
spared B a possible infection, but I'm reluctant to blame A's MX for
this: it didn't originate, accept or transfer the malware-laden message.
I think responsibility lies with M, and/or with whatever system passed
the message to M (presuming the message didn't originated on M).

Well, regardless of who is pointing the finger at who, the fact remains 
that:
  1) an infected E-mail is being passed on to someone who quite likely 
had NOTHING to do with sending it, nor did they probably have any 
control over the system(s) that did;
  2) the extra bandwidth was wasted by sending mail to someone who 
didn't want it, and who can't do anything about it;
  3) the resulting infected E-mail is now coming from a computer whose 
IP address is likely in the (actual final) recipient's "trusted" zone, 
whereas the original actual origin system might well not be.
> While this is a less-than-desirable outcome, I think it may be the best
we can do -- we can't block something before we see it, we can only do
our best to reject outright spam/malware/junk traffic at the earliest
available opportunity.  (One of the ways I've expressed this elsewhere
is that the best place to stop spam is as near its source as possible.
The farther it gets from the origin, the trickier detecting it gets,
and the greater the possible consequences.)

Actually, I believe that that philosophy is incorrect.

First of all, ultimately the ONLY authority which TRULY determines FOR A 
FACT whether a given piece of e-mail is unwanted or not is the final 
recipient.
Other people enroute might conclude that something PROBABLY is spam, but 
they cannot be sure.
I understand the desirability of stopping spam and viruses as close to 
the sender as possible, WHERE THAT IS POSSIBLE, but I suggest that it 
often is not.
ULTIMATELY, the recipient of the message (i.e. the addressee, not 
necessarily the place where it ultimately gets bounced to) has a KEY 
piece of information that MTAs enroute do not have:  the knowledge of 
the (prior?) trust relationship that exists between the addressee and 
the purported sender.
And, let me point out, this even varies WITHIN a single addressee:  I 
have more than one E-mail address, and use them for different purposes. 
 An E-mail message arriving at the "wrong" address might indicate that 
it is unwanted, EVEN IF THE SAME SENDER MIGHT BE EXPECTED TO MAIL TO ME 
AT A DIFFERENT ONE OF MY ADDRESSES.
This is part of why I still believe that a finely-grained "permissions 
list", based on the recipient/orignator e-nmail address pair, AND having 
access by then to the WHOLE message, can do a SIGNIFICANTLY better job 
of accurately performing the spam/nospam triage than ANY more 
generalized SMTP-level MTA could ever hope to do enroute.
As I have pointed out before, if I get an e-mail containing an 
executable (a control panel applet, a hard .EXE file, even a piece of 
Java script or Active X enclosure or whatever) from someone who (a) I do 
not know, or (b) who I might know but who I do not expect to send me 
something like THAT, then it's perfectly reasonable to treat that e-mail 
as at least HIGHLY suspect.
Now, there ARE people I correspond with who I might EXPECT to send me 
stuff like that, or at least SOME of those sorts of things;  obviously 
those should come through to me fine.  But there may be OTHER things I 
would expect to see in mail from those trusted and familiar 
correspondents;  for example, their familiar sig that they put on the 
e-mails they send out to me, or the masthead I normally see on their 
e-newsletter, or whatever.  Even maybe the familiar way they address me 
in the accompanying message.
Note that this is not unlike the way most of us actually handle "spam 
triage" in our inboxes now:  we look to see mail coming from unfamiliar 
senders, or unfamiliar subjects, or for that matter common spam-type 
subject lines.  The key thing is that mail coming from an address we 
recognize might encourage us to look more closely at mail which we might 
not give a second thought to deleting if it came from someone unfamiliar.
I personally think that mail containing attachments (of any type) or 
HTML (scripting, ActiveX, misrepresentable links, etc) coming from 
people I don't know and trust are primary examples of mail that stands a 
strong probability of being unwanted (or at the very least, untrusted).
Now, I would agree that e-mail containing certain types of things can 
probably be axed at a very early point in the delivery process (an 
example would be mail containing a recognized virus content, especially 
a virus known to falsify return addresses...!)
BUT it is also VERY frustrating when, for example, I find that an 
absolutely legitimate e-mail message I have sent out gets bounced back 
to me by someone enroute, containing something like:
[quote]

Diagnostic-Code: smtp; 554 The message was rejected because it contains
    prohibited virus or spam content (in reply to end of DATA command)

[end quote]

...and particularly when the message contains neither virus nor spam, 
and where I have not the slightest idea of who I would need to try to 
contact (and where, or how) to solve the non-delivery problem.
And I presume that the addressee I was sending the mail to has similarly 
no idea of who they would need to complain to about our mail being 
intercepted and waylaid enroute.
Given the choice, I like the simplicity and correctability of people 
enroute delivering the mail as requested, and having the recipient's 
mail client (given the additional knowledge that only it has!) doing the 
BETTER possible job of deciding how to perform the triage.
--

Gordon Peterson II
http://personal.terabites.com
1977-2007:  Thirty year anniversary of local area networking
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg