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

> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of
> [email protected]
> Sent: Monday, January 10, 2005 2:52 PM
> To: [email protected]; [email protected]
> Cc: [email protected]
> Subject: RE: blowback, was A new SMTP "3821" [Re: FTC
> stuff...........]
>
>
>
> > From: Dean Anderson [mailto:[email protected]]
> > On Sun, 9 Jan 2005 [email protected] 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,"
>