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

The blowback issue is different from this. Blowback happens whenever
anyone _rejects_ emails based on SPF.

Fair enough

A bounce is generated from the relay to the forged sender.

Is it? If the receiving MTA issues an SMTP reject command, it does not
assume any responsibility for the delivery of the mail. It will
therefore not generate a spurious bounce message.

This isn't how most current SMTP servers behave.
(Sendmail/Qmail/Postfix/Exchange, anyway) If the receiving MTA rejects
mail, the sending MTA generates a bounce to the sender. The sender of
course, can be forged.

Post by M***@hbinc.com
If the sending MTA generates a bounce message, then it's likely not a
virus or other malware likely to forge a sender address.

???

This too is wrong. Many viruses send "forged" bounces containing a virus.
One cannot assume that because you opened a bounce, the message will not
contain a virus. Further, a genuine bounce with an undelivered message
may contain a virus in the undelivered message.

Post by M***@hbinc.com
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,"

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

t***@ashtonwoodshomes.com

2005-01-10 01:43:36 UTC

-----Original Message-----
Sent: Sunday, January 09, 2005 7:39 PM
Subject: RE: blowback, was A new SMTP "3821" [Re: FTC
stuff...........]

The blowback issue is different from this. Blowback

happens whenever

anyone _rejects_ emails based on SPF.

Fair enough

A bounce is generated from the relay to the forged sender.

Is it? If the receiving MTA issues an SMTP reject command,

it does not

Post by M***@hbinc.com
assume any responsibility for the delivery of the mail. It will
therefore not generate a spurious bounce message.

This isn't how most current SMTP servers behave.
(Sendmail/Qmail/Postfix/Exchange, anyway) If the receiving
MTA rejects
mail, the sending MTA generates a bounce to the sender. The
sender of
course, can be forged.

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!

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.

Post by M***@hbinc.com
If the sending MTA generates a bounce message, then it's

likely not a

Post by M***@hbinc.com
virus or other malware likely to forge a sender address.

???
This too is wrong. Many viruses send "forged" bounces
containing a virus.

The statement was that virus infected machines don't usually process bounces if an MTA rejects its
transmission attempt. And the statement *is* correct.

One cannot assume that because you opened a bounce, the
message will not
contain a virus. Further, a genuine bounce with an
undelivered message
may contain a virus in the undelivered message.

True, but what is your point? The question at hand was "If the MTA rejects a message, does this
cause a blowback problem":
Case 1: Message is arriving from the virus itself:
-no blowback, viruses will usually ignore the rejection

Case 2: Message is arriving from an MTA that accepted the message from a virus:
-no sympathy for the bounce, the MTA should have rejected the virus message in the first place.
Is there a real issue with blowback? NO: There are plenty of ways of dealing with blowback until
all the MTA's are upgraded to provide some sort of MTA authentication to deal with forgery and
reject it at the first hop. (Yes, even silently dropping the bounces, something which large ISP's
often do already ANYWAY).

Terry Fielder

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

Dean Anderson

2005-01-10 19:44:16 UTC

Post by t***@ashtonwoodshomes.com
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?

You are talking about a normal closed relay. It cannot use SPF to validate
its own users.

Post by t***@ashtonwoodshomes.com
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

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

M***@hbinc.com

2005-01-10 19:51:43 UTC

Post by t***@ashtonwoodshomes.com
Agreed, but near sighted. If the sending MTA had done some

sort of validation to ensure the message

Post by t***@ashtonwoodshomes.com
was not forged when it accepted it, then we wouldn't have a

blowback problem. You cannot blame

Post by t***@ashtonwoodshomes.com
subsequent MTA's in the path for detecting and rejecting

bad email when its something the first hop

Post by t***@ashtonwoodshomes.com
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.

Post by t***@ashtonwoodshomes.com
His point I think is that if the virus is trying to send

directly to the MTA it would get rejected

Post by t***@ashtonwoodshomes.com
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

Post by t***@ashtonwoodshomes.com
forged, and MTA.1 processes a bounce, well, NO SYMPATHY FOR

MTA.1, it should have taken steps to

Post by t***@ashtonwoodshomes.com
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,"

t***@ashtonwoodshomes.com

2005-01-10 20:05:29 UTC

-----Original Message-----
Sent: Monday, January 10, 2005 2:52 PM
Subject: RE: blowback, was A new SMTP "3821" [Re: FTC
stuff...........]

Post by t***@ashtonwoodshomes.com
Agreed, but near sighted. If the sending MTA had done some

sort of validation to ensure the message

Post by t***@ashtonwoodshomes.com
was not forged when it accepted it, then we wouldn't have a

blowback problem. You cannot blame

Post by t***@ashtonwoodshomes.com
subsequent MTA's in the path for detecting and rejecting

bad email when its something the first hop

Post by t***@ashtonwoodshomes.com
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).

Post by t***@ashtonwoodshomes.com
His point I think is that if the virus is trying to send

directly to the MTA it would get rejected

Post by t***@ashtonwoodshomes.com
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

Post by t***@ashtonwoodshomes.com
forged, and MTA.1 processes a bounce, well, NO SYMPATHY FOR

MTA.1, it should have taken steps to

Post by t***@ashtonwoodshomes.com
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

Post by t***@ashtonwoodshomes.com
taking steps to prevent viruses does not catch all virues.

Even using

Post by t***@ashtonwoodshomes.com
SMTP AUTH on a closed relay does not prevent forgery.
--Dean

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

Dean Anderson

2005-01-10 21:08:12 UTC

Post by t***@ashtonwoodshomes.com
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 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.

Post by t***@ashtonwoodshomes.com
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.

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

Dean Anderson

2005-01-11 15:36:19 UTC

Post by t***@ashtonwoodshomes.com
Agreed, but near sighted. If the sending MTA had done some

sort of validation to ensure the message

Post by t***@ashtonwoodshomes.com
was not forged when it accepted it, then we wouldn't have a

blowback problem. You cannot blame

Post by t***@ashtonwoodshomes.com
subsequent MTA's in the path for detecting and rejecting

bad email when its something the first hop

Post by t***@ashtonwoodshomes.com
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.

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.

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

M***@hbinc.com

2005-01-10 19:53:06 UTC

From: Matthew.van.Eerde
If MTA.2 then turns around and delivers the virus to someone else, that is not my problem.

Er, I meant to say, If MTA.1 turns around etc.

M***@hbinc.com

2005-01-10 21:16:28 UTC