ietf-mxcomp
[Top] [All Lists]

RE: blowback, was A new SMTP "3821" [Re: FTC stuff...........]

2005-01-10 13:06:22
-----Original Message-----
From: owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of
Matthew(_dot_)van(_dot_)Eerde(_at_)hbinc(_dot_)com
Sent: Monday, January 10, 2005 2:52 PM
To: dean(_at_)av8(_dot_)com; terry(_at_)ashtonwoodshomes(_dot_)com
Cc: ietf-mxcomp(_at_)imc(_dot_)org
Subject: RE: blowback, was A new SMTP "3821" [Re: FTC
stuff...........]



From: Dean Anderson [mailto:dean(_at_)av8(_dot_)com]
On Sun, 9 Jan 2005 terry(_at_)ashtonwoodshomes(_dot_)com wrote:


Agreed, but near sighted.  If the sending MTA had done some
sort of validation to ensure the message
was not forged when it accepted it, then we wouldn't have a
blowback problem.  You cannot blame
subsequent MTA's in the path for detecting and rejecting
bad email when its something the first hop
MTA could (and should) have done in the first place!

And just what sort of validation would that be?

Authentication (SMTP AUTH, POP-before-SMTP, etc.),
restriction to trusted IP addresses, etc.  Basically the
sending server is responsible for authorizing its own use,
via whatever method is most appropriate.

And let's not forget that the authorization can also include SPF-Classic or 
even Unified SPF (if ot
goes anywhere) (or even if you like bad things to happen PRA).  That would 
ensure that authorized
clients of the MTA.1 whose machines are infected cannot forge the From address, 
hence the bounce
generated by MTA.1 when MTA.2 rejects the email will go somewhere not forged 
(i.e. the infected
machine or at least someone from that domain).


His point I think is that if the virus is trying to send
directly to the MTA it would get rejected
with no bounce back (because the virus wouldn't process a bounce).

If an MTA.1 accepted a virus message, and tried relaying it
to MTA.2, when MTA.2 rejects it as
forged, and MTA.1 processes a bounce, well, NO SYMPATHY FOR
MTA.1, it should have taken steps to
prevent the virus/forgery etc from being accepted by itself
in the FIRST PLACE.

Your lack of sympathy for MTA.1 is unfortunate, but
unrealistic.  Even
taking steps to prevent viruses does not catch all virues.
Even using
SMTP AUTH on a closed relay does not prevent forgery.

            --Dean

I have the greatest sympathy for MTA.1 and its users.  My
sympathy (as MTA.2's admin) does NOT extend to taking
responsibility for delivery of the viruses MTA.1 is trying to
unload on me.  If MTA.1 then turns around and delivers the
virus to someone else, that is not my problem.

Exactly.


With my particular MTA.2, I reject virii even if they are to
valid addresses.

Definitely the best course of action.

If this causes MTA.1 to deliver a bounce
message (possibly even including the virus) to the forged
sender, then MTA.1 just made a big mistake.

Exactly.

I suppose a case
could be made that it's "my fault" somehow, but I'm not going
to lose any sleep over it.

Sorry to say "what he said", but it is *so* important and seems to get 
overlooked by those rejecting
SPF, I felt the need to chime in.

Terry Fielder


Matthew.van.Eerde (at) hbinc.com                 805.964.4554 x902
Hispanic Business Inc./HireDiversity.com         Software Engineer
perl -e"map{y/a-z/l-za-k/;print}shift" "Jjhi pcdiwtg Ptga wprztg,"

<<attachment: winmail.dat>>