Subject: RE: DEPLOY: Legal liability for creating bounces from forged messages

From: "Jim Lyon" <[email-masked]>
Date: Tue, 24 Aug 2004 14:34:08 -0700

Regarding generation of bounces vs. rejecting mail at SMTP time, John
Glube raises a number of issues:

> * Your position presumes wide spread implementation of
> Submitter, allowing for extraction of the PRD at the data
> stage.

No. SUBMITTER allows you to reject the message at MAIL command time.
Without SUMBMITTER, you can extract the PRD during receipt of the
message, and reject the message and end-of-data time.

> * Until this happens, as Sender-ID is presently drafted,
> the receiving MTA has to 'swallow' the message and extract
> the PRA from the headers. As has been previously stated
> this leads to a greater risk of false positives.

Without SUBMITTER, the receiving MTA has to receive the message,
but does not need to accept it.  The risk of false positives is
identical whether SUBMITTER is used or not.  SUBMITTER merely
lets the receiver do the test earlier, saving bandwidth for
both sender and receiver if the message is destined for refusal.

> * Sender-ID does not call for SMTP mail from checks at the
> DATA stage in the absence of PRA. If you are suggesting
> either amending Sender-ID or preparing a BCP document to
> suggest that receivers do carry out SMTP mail from checks
> at the DATA stage in the absence of PRA, I would whole
> heartedly support this.

I'm not sure what you mean by "the absence of PRA". If you mean
"the absence of SUBMITTER", then the current docs certainly
contemplate this.  They even tell you what message to use
when rejecting mail.  (If you mean something else, I'm afraid I
completely missed your point.)

> (lots more words arguing that most spam is sent by zombies.)

Yes, it is.  But the zombies tend to run specialized spam engines,
not real MTAs.  And they don't generally send the mail through
the zombied machine's ISP's MTA, they send it directly to the
recipient.

-- Jim Lyon

---

From: "John Glube" <[email-masked]>
Date: Tue, 24 Aug 2004 18:29:27 -0400

From: Jim Lyon 
Sent: August 24, 2004 5:34 PM

Draft marid submitter states in the Introduction on page 2:

>Deriving the purported responsible domain from RFC 2821
>data has the advantage that validation can be performed
>before the SMTP client has transmitted the message body. 
>If spoofing is detected, then the SMTP server has the
>opportunity, depending upon local policy, to reject the
>message before it is ever transmitted."

However draft marid core states in the Negative problem
statement at page 2:

>Following are several alternate questions, which this
>specification makes no attempt to answer:

>   1. Is the host at a particular IP address authorized to
>act as an SMTP client?

>   2. Is an SMTP client authorized to use a particular
>domain name in its SMTP EHLO command?

>   3. Is an SMTP client authorized to use a particular
>email address in an SMTP "MAIL FROM:" command?

>   4. Was a message really authored by who it claims to be
>authored by?

The point being as noted by Chris Haynes in the thread
"What Meng Said" where he wrote:

>Meng,

>Please may I ask a brutally simple question.

>I think it is generally agreed that where MAIL-FROM == PRA
>any decision is based on the PRA.

>My question below applies only to those messages in which
>the domain of the MAIL-FROM is different from the domain of
>the PRA.

>Where, in the collection of drafts issued on Friday, does
>Sender-ID refer to the rejection of a message as a result
>of evaluating the record associated with its MAIL-FROM
>domain?

>Chris Haynes

http://www.imc.org/ietf-mxcomp/mail-archive/msg03306.html

To which Meng responded:

>Sender ID as currently specified doesn't do that.

>If people want the MAIL FROM to play a role in Sender ID,
>they should say so.  If they do not say so, the working
>assumption is that nobody cares.

>I personally think that if the PRA lookup returns "none" or
>"unknown", MAIL FROM should be checked, and if that test
>returns "fail" then the message should be rejected.

http://www.imc.org/ietf-mxcomp/mail-archive/msg03324.html 

- and my follow up message -

http://www.imc.org/ietf-mxcomp/mail-archive/msg03339.html

I am speaking of this issue, which in turn includes the
concern raised by Nate Leon when he wrote in part:

>For completeness, here is another example of the concern:

>MAIL FROM:<>                            // don't care
>RCPT TO:<valid-recipient@xxxxxxxxxxx>         

>DATA

>Subject: update your account info Resent-From:
>JoePhisher@xxxxxxxxxxxxxxxx            // valid domain
>authenticated by MARID ... 
>From: account-services@xxxxxxxxxxxx    // Spoofed domain,
>displayed by the MUA To:
>valid-recipient@xxxxxxxxxxx            // bummer for you   

>...  Are we really going to RFC with this issue left
>open?

http://www.imc.org/ietf-mxcomp/mail-archive/msg03372.html

Harry Katz's responses:

http://www.imc.org/ietf-mxcomp/mail-archive/msg03375.html

- and -

http://www.imc.org/ietf-mxcomp/mail-archive/msg03416.html

and my message in response:

http://www.imc.org/ietf-mxcomp/mail-archive/msg03443.html

Also see the following three message:

My message found at:
http://www.imc.org/ietf-mxcomp/mail-archive/msg03417.html

- and -

Daryl Odnert's response:

http://www.imc.org/ietf-mxcomp/mail-archive/msg03421.html

- and -

My reply:
http://www.imc.org/ietf-mxcomp/mail-archive/msg03458.html

These messages reflect the deployment issues I am raising
with marid-protocol/marid-core and which remain outstanding.

Please also note the last statement from Chris Haynes in
his most recent message:

>And incorporating the tests & semantics developed in SPF
>would result in even fewer bounces - and totally eliminate
>the situations which concern me.

Trusting this makes my position clearer.

John Glube
Toronto, Canada

The FTC Calls For Sender Authentication
http://www.learnsteps4profit.com/dne.html

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.737 / Virus Database: 491 - Release Date: 11/08/2004

---

From: Mark Shewmaker <[email-masked]>
Date: Tue, 24 Aug 2004 18:48:42 -0400

> message, and reject the message and end-of-data time.

No:  Without SUBMITTER, you still might have to bounce, (not reject)
messages after end-of-data time.  This can happen if one recipient has
white-listed the PRA, but another recipient hasn't.

If the MTA server were given a SUBMITTER parameter, it could have done
per-user rejects at RCPT TO: time, and avoided the need for bounces
altogether.

However, if the MTA server isn't given a SUBMITTER parameter, then
differences between recipient white-listings can cause the MTA to have
to accept the message and then generate bounces for the non-white-listed
recipients.

The only potential solutions I can see are:

1.  Unified SPF, so that MAIL FROM is always checks:  This is only a
    partial solution unfortunately.  It can only filter out some forged
    Return-Path's.

2.  An SMTP extension to do per-user after-data rejects:  This would be
    a great extension, but until almost everyone uses it we couldn't
    require it.

3.  In the case of differing per-recipient white-lists, rejecting all
    recipients from the first contrary one onwards with a "too many
    recipients" transient error.

    This violates RFC 2821, as you're supposed to always be able to
    accept at least 100 recipients, but I think it might be the only
    sure-fire solution that can handle this problem, and that doesn't
    assume the rest of the world upgrades to newer SMTP extensions.

I think choice #3 is the only viable choice.  It's ugly, but it's the
only thing that can really prevent this bounce-generation problem.

-- 
Mark Shewmaker
[email-masked]

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 25 Aug 2004 12:17:28 +0200

On Tue, Aug 24, 2004 at 06:29:27PM -0400,
 John Glube <[email-masked]> wrote 

> >email address in an SMTP "MAIL FROM:" command?
...
> >assumption is that nobody cares.
...
> with marid-protocol/marid-core and which remain outstanding.

Is it unrealistic to assume that, if the current Sender-ID becomes a
RFC as it is, nevertheless, some people will use SPF records (as
specified in -protocol) to perform checks on the 2821 MAIL FROM and
not only on the official PRA?

A sort of unofficial "Unified SPF"?

---

From: Jeff Macdonald <[email-masked]>
Date: Wed, 25 Aug 2004 13:21:49 -0400

> not only on the official PRA?

That is my thinking exactly. Someone will create a tool that combines
all these checks.

> A sort of unofficial "Unified SPF"?

Or a new RFC or BCP that would take all those ideas and combine it into
one.