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

From: <[email-masked]>
Date: Mon, 10 Jan 2005 11:51:43 -0800

> From: Dean Anderson [mailto:[email-masked]]
> On Sun, 9 Jan 2005 [email-masked] 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.
 
> > 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.2 then turns around and delivers the virus to someone else, that is not my problem.

With my particular MTA.2, I reject virii even if they are to valid addresses.  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.  I suppose a case could be made that it's "my fault" somehow, but I'm not going to lose any sleep over it.

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,"

---

From: <[email-masked]>
Date: Mon, 10 Jan 2005 15:05:29 -0500

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

> 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

---

From: Dean Anderson <[email-masked]>
Date: Mon, 10 Jan 2005 16:08:12 -0500 (EST)

On Mon, 10 Jan 2005 [email-masked] wrote:

> 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 this stops forgery how? 

I think you're forgeting that _every_ user (including every spammer and 
forger, and virus-infected computer) has relay services provided by their 
provider. They have those services right up until they don't.

SPF takes for granted that the ISP's users can forge email to the ISPs 
relay, and doesn't address that problem.  This opens the possibility for 
100% blowback.

> 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.2 then turns around
> and delivers the virus to someone else, that is not my problem.
>
> With my particular MTA.2, I reject virii even if they are to valid
> addresses.  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.  I suppose a case could be made that it's "my fault"
> somehow, but I'm not going to lose any sleep over it.

You may reject some virii. But I think you don't reject all virii, either
because your virus definitions aren't uptodate every second of the day, or
because a new virus has emerged which isn't in the detection database.

Supposing you say, "I don't accept any attachments", then I'd point out 
that this is insufficient to prevent infection, since a link to a rogue 
server is enough to infect a computer. 

Supposing you say, "I don't allow html email", then I'd point out that 
abusers can still send a URL in text, an the unsuspecting user might type 
it into their browser and get infected.

Supposing you say, "My users are too smart to fall for that", I'd say: 
congratulations. But it doesn't scale.

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000

---

From: Dean Anderson <[email-masked]>
Date: Tue, 11 Jan 2005 10:36:19 -0500 (EST)

> for authorizing its own use, via whatever method is most appropriate.

None of the things you listed indicate prevent forgery.  Server 
authorization is not related to forgery.  As I pointed out, Closed relays 
are "authorized", but one can still forge emails.  SMTP AUTH and 
Pop-before-SMTP don't prevent forgery, either.

As I already pointed you, you keep forgetting that every abuser is 
someone's customer, and so has access to relay facilities. Those 
facilities cannot prevent forgery.