Subject: RE: Point of Order: Incomplete, flawed response to MARID WG Chart er

From: "Daryl Odnert" <[email-masked]>
Date: Wed, 18 Aug 2004 10:55:42 -0700

Chris,

In your example, it wasn't clear to me whether or not the
the small business domain published a Sender ID policy
in the DNS.

Assuming the domain did not publish any policy data, the
receiving MTA cannot perform the Sender ID test if there
is no policy information in the DNS, so the message should
not be rejected with a 550 error unless it has is some other
good reason to do so.

On the other hand, if the domain did publish a Sender ID
policy and the message is rejected for policy reasons, then
either the policy data is inaccurate or the ISP is doing
something to the message that it shouldn't be doing.

So, I still don't understand the crux of your complaint
about Sender ID here.  How is Sender ID causing any harm
to anyone here?

Daryl Odnert
Tumbleweed Communications
Redwood City, California

====
Chris' example:

Small business:  (Virus on) End user MUA sends message to internal MTA,
which
stores-and-forwards message to public-facing MTA of the business' ISP.

This ISP-MTA has not implemented Sender-ID, so does no know that the PRA
will
later be detected as a forgery. This ISP is generally slack about security,
adding Resent-From headers, etc.

ISP-MTA accepts message for onward delivery, cannot initially contact
destination MTA, stores message and undertakes to try again later.

Second attempt to contact destination MTA succeeds.

Destination MTA applies Sender-ID, rejects message during SMTP protocol
exchange
with a '550'.

ISP-MTA notes the '550' and fulfils its 'contract' by generating a
non-delivery
"Bounce" message, which is sent to the address in "Mail-From" in the
original
(virus-generated?) message.

---

From: "Chris Haynes" <[email-masked]>
Date: Thu, 19 Aug 2004 08:53:08 +0100

RE: Point of Order: Incomplete, flawed response to MARID WG CharterDaryl,

Perhaps it will help if I summarise my understanding of how Sender-ID (and SPF) actually work.

My example was of an outbound, stored message in which the PRA (e.g. "From:") was forged.

The "To:" address is that of a valid recipient.

The 'Mail-From:' address is a real address, but that of an 'innocent victim' who has no connection whatsoever with the small business or the ISP.

In Sender-ID (and in SPF) it is the policy of the domain which the message claims to be from (the _Purported_ Responsible Address and the Mail-From address respectively) which is consulted, not the policy of the domain of the host attempting to send the message.

So, as the message does not claim to come from the small business, it does not matter one jot whether or not the small business has published a record, and whether or not that record identifies the outbound MTA as a valid sender of its messages.

It will be the record of the domain which has been forged which will be consulted, and as that domain's record will not have authorised this particular MTA host to send its messages, the message will be rejected and Sender-ID will have worked as required.

However, with Sender_ID, the host which was attempting to send the Original (stored) message will now create and send a Bounce message to whatever address the forger decided to put into the Mail-From header. It may well also put a full copy of the original message (including virus, sexually-explicit spam, etc.) into that message.  

That virus-carrying message will now be sent, unauthorised and unchecked by Sender-ID, to whatever innocent victim was chosen by the forger. 

This is the 'harm' that Sender-ID would be causing.  If Sender-ID had not been used, this second, virus-carrying message would not have been created and sent. 

Headline summary: Sender-ID propagates viruses!

One really significant difference between Sender-ID and SPF is that SPF prevents both messages being sent.  

SPF inspects the Mail-From address and asks its domain record if the host currently attempting to send the original message is authorised to use that Mail-From address. 

If the SPF test result is 'fail' (i.e. if the domain record derived from the Mail-From address says "I _never_ use that host") the message is proven to be unauthorised, the SMTP 'Deliver-or-Bounce' commitment is null-and-void, so the outbound message is discarded and no bounce is generated.

To return to the essence of my original question to the Chair, Sender-ID only seeks authority for the Original message. No authority is sought for Bounce messages.

SPF seeks authority for _both_ messages - thus covering the whole of the MARID charter's problem-space.

[Note, I use SPF solely as a 'proof-of-existence' of technology which has demonstrated its ability to validate the authorities of both messages. As far as I am aware, SPF has not formally been submitted to the IETF, so has not yet undergone the rigorous engineering inspection which Sender-ID is now undergoing. It would appear that there may also be other as-yet-unsubmitted candidate technologies to be considered].

HTH

Chris

  ----- Original Message ----- 
  From: Daryl Odnert 
  To: 'Chris Haynes' 
  Cc: IETF MARID WG 
  Sent: Wednesday, August 18, 2004 6:55 PM
  Subject: RE: Point of Order: Incomplete, flawed response to MARID WG Chart er

  Chris, 

  Daryl Odnert 

  ==== 
  Chris' example: 

  Small business:  (Virus on) End user MUA sends message to internal MTA, which 
  stores-and-forwards message to public-facing MTA of the business' ISP. 

  This ISP-MTA has not implemented Sender-ID, so does no know that the PRA will 
  later be detected as a forgery. This ISP is generally slack about security, 
  adding Resent-From headers, etc. 

  Destination MTA applies Sender-ID, rejects message during SMTP protocol exchange 
  with a '550'. 

  ISP-MTA notes the '550' and fulfils its 'contract' by generating a non-delivery 
  "Bounce" message, which is sent to the address in "Mail-From" in the original 
  (virus-generated?) message.

---

From: Roy Badami <[email-masked]>
Date: Thu, 19 Aug 2004 14:39:36 +0100

>>>>> "Chris" == Chris Haynes <[email-masked]> writes:

    Chris> That virus-carrying message will now be sent, unauthorised
    Chris> and unchecked by Sender-ID, to whatever innocent victim was
    Chris> chosen by the forger.

    Chris> This is the 'harm' that Sender-ID would be causing.  If
    Chris> Sender-ID had not been used, this second, virus-carrying
    Chris> message would not have been created and sent.

Backscatter (ie bounce messages sent to forged addresses) is already a
_huge_ problem for many people, and will need to be solved whatever
happens in the MARID front.

People are working on it (schemes that modify the MAIL FROM such as
BATV or SES, schemes that keep track of Message-IDs, schemes that add
additional tracking headers).

Your argument basically boils down to saying I should never reject any
SMTP transaction because it might result in backscatter.  I don't buy
it.  Backscatter is a problem; let's fix it (but not here).

     -roy

---

From: "Chris Haynes" <[email-masked]>
Date: Thu, 19 Aug 2004 16:59:26 +0100

At  2:39 PM on  Thursday, August 19, 2004  "Roy Badami" said:

<snip>
> it.  Backscatter is a problem; let's fix it (but not here).
<snip>

No, it does not.

I was pointing out that:
1) Sender-ID makes the backscatter problem worse,
2) SPF can in many cases make it better, but never worse.

AFAICT, no one has a proven universal solution to offer.

What can be done, and is now being done in this anti-forgery activity, is to
deploy a sequence of relatively simple schemes which gradually chip away at
parts of the problem, forcing the bad guys to change their behaviour in ways
which makes it progressively more difficult / more expensive for them to act,
and easier for them and their works to be identified and dealt with.

What we have to ensure, however, is that these simple schemes do not have
unintended, avoidable side-effects, or at least that, if they do, there is a
proper, engineering evaluation of the overall cost-benefit before deciding to
deploy them.

It occurs to me that this process is rather like that which public health
experts must go through when deciding on programs of public immunisation. A
vaccine which gives benefit / protection to the many may have the side-effect of
causing vaccine-damage to a minority.

This current debate is about an undesirable side-effect of Sender_ID, and one
which is avoidable if the essence of SPF is added to the 'vaccine' at the same
time.

Ethically, which do you do:

-  Rush out a single-strain vaccine with a known adverse side-effect, or
-  Spend another three or four weeks mixing a 'cocktail' which
      avoids that side-effect?

I think that is the choice facing this working group.

Chris

---

From: Roy Badami <[email-masked]>
Date: Thu, 19 Aug 2004 19:08:42 +0100

>>>>> "Chris" == Chris Haynes <[email-masked]> writes:

    Chris> No, it does not.

    Chris> I was pointing out that: 
    Chris> 1) Sender-ID makes the backscatter problem worse,
    Chris> 2) SPF can in many cases make it better, but never worse.

Really?  draft-mengwong-spf-01 permits rejection of a message with a
550 reply code if the SPF check fails, and that's what most
implementations seem to do.

If you reject an SMTP transaction due to an SPF failure, then the
up-stream MTA is likely to generate a bounce to a forged address.

As far as I can see, all MARID schemes are likely to increase
backscatter.  In fact, anything that cause more mail to be SMTP
rejected will increase backscatter.

	 -roy

---

From: Meng Weng Wong <[email-masked]>
Date: Fri, 20 Aug 2004 16:54:59 -0400

On Thu, Aug 19, 2004 at 07:08:42PM +0100, Roy Badami wrote:
| 
| Really?  draft-mengwong-spf-01 permits rejection of a message with a
| 550 reply code if the SPF check fails, and that's what most
| implementations seem to do.
| 
| If you reject an SMTP transaction due to an SPF failure, then the
| up-stream MTA is likely to generate a bounce to a forged address.

1) If the sender is an MTA sending on behalf of a legitimate
sender, then the rejection is, in spirit, a false positive.
The rejection is a good thing because it informs the
legitimate sender that their message didn't get through.

2) If the SMTP sender is a virus, then the rejection does not
cause a nondelivery notification, and there is no problem.

3) If the sender is an MTA sending on behalf of a virus, the
nondelivery notification is generated by that MTA, and it's
the fault of that MTA for being gullible.  If the message
had been rejected for some reason other than SPF, for
example due to over-quota at final delivery, the forged
sender gets backscatter anyway.

| As far as I can see, all MARID schemes are likely to increase
| backscatter.  In fact, anything that cause more mail to be SMTP
| rejected will increase backscatter.

Scenarios 1 and 2 are desirable.

Scenario 3 is no worse than the current situation.

Scenario 4 is avoided: the SMTP sender is a virus, the
receiving MTA accepts the message, and sends a message to
a bogus return path.

The benefit from stopping 4, plus the benefits of 1 and 2,
are worth the costs of 3, which is net no worse than the
"priors" anyway.

Therefore a scheme which checks mail-from is not proven to
increase backscatter, and it is not true that anything that
causes more mail to be SMTP rejected will increase
backscatter.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 20 Aug 2004 16:20:09 -0700

When the Front-Door is locked, they'll use the Back-Door left open.

RFC2821 MAIL FROM protections in general terms:

1) MAIL FROM checked before accepted:
 a- caused by a virus - Good Reject
 b- illicit spam technique - Good Reject
 c- channel config error - Good Reject
 d- other rejections - Good Reject

2) MAIL FROM checked after accepted, but before bounce:
 a- caused by a virus, checked against prescribed channel - Bad Send
 b- caused by a virus, checked with local-part signature - Good Drop
 c- illicit spam, checked against prescribed channel - Bad Send
 d- illicit spam, checked against local-part signature - Good Drop
 e- channel config error, checked against prescribed channel - Good Send
 f- other rejections - Good Send

3) RCPT TO <MAIL FROM> Bounce:
 a- caused by virus, checked against prescribed channel - Bad Accept
 b- caused by virus, checked against local-part signature - Good Reject
 c- illicit spam, checked against prescribed channel - Bad Accept
 d- illicit spam, checked against local-part signature - Good Reject
 e- channel config error, checked against prescribed channel - Unknown
 f- other rejections, checked against prescribed channel - Unknown
 g- other rejections, checked against local-part signature - Good Accept

1)
MAIL FROM checks prior to acceptance is always good and will lower the
amount of bounce traffic that may occur for other reasons at subsequent
processes such as virus filtering or unknown recipient at subsequent
MTAs. Its all good.

2)
MAIL FROM checks after acceptance depends heavily upon the type of
checking.  If the check is based upon a prescribed mail channel, then
due to a likelihood of this prescription being wrong, the bounce should
be sent.  Proper practices should be able to avoid this problem, unless
the overhead is considered too great for the check to be done for each
message.  If the check is based upon a local-part signature, then when
this check is made is less critical.

3)
The RCPT TO / MAIL FROM bounce depends fully upon the check made.  It
also illustrates far end cooperation is not needed for the case where
the local-part signature is checked.  Combined with a nounce, this check
can limit the number of replays somewhat, in addition to expiry
timeout.  A channel check could help reduce a potential local-part
signature replay problem.  This breakdown assumes illicit use will
ensure the defeat of a channel check.

-Doug