Subject: Open relay test (was: Bounce/System Notification Address Verification)
From: Frank Ellermann <[email-masked]>
To: [email-masked]
Date: Fri, 01 Jul 2005 08:26:59 +0200
List-Id: <ietf-smtp.imc.org>

Hector Santos wrote:

> I did learn one new trick that I think I will implement and
> explore - flip it around, test the random address first.
> If accept, it is operating in an open relay behavior.

It could be also a "teergrube" accepting one character per
second after DATA (with a 5xx after the data).  You're not
testing a dummy (empty) DATA, or are you ?  I report this
crap as spam.
                        Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  PRA question (was: Bounce/System Notification Address Verification)
Date:  Fri, 01 Jul 2005 07:47:03 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 37
Sender: [email-masked]

Hector Santos wrote:

> The PRA is:
>       Resent-Sender
>       Resent-From:
>       Sender:
>       From:

> In that order, but the PRA also has logic for the group
> positions of the headers, including Return-Path.

I've never heard that they do anything with a Return-Path.

The "position" is just top down hoping to catch the most
recent Resent-block.  That stuff wasn't really discussed
with experts like Bruce, Keith, or Ned, and so re-ordered
header fields never really entered the picture.  <shrug />

> Microsoft calls it a "Complex" PRA lookup logic, so
> complex, its patented!

It's about as complex as read and understand chapter 3.6.6
in RFC 2822 goes.  April 2001, long before the patent claim.

> So in short,  SenderID/PRA ignores the Mail From: when in
> fact, a good bit of the time, over 80% based on my logs:

>             2822.PRA  = 2821.MAIL FROM

Nice, under 20% of erroneous results by abusing v=spf1 for PRA
without explicit consent of the publisher.

The general IETF list discusses the meaning of the "S" in IESG,
so maybe the question what the "E" does NOT stand for is clear.

                      Bye, Frank

From: "Hector Santos" <[email-masked]>
To: <[email-masked]>
Cc: "Tony Finch" <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification
Date: Thu, 30 Jun 2005 17:43:54 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

Follow up:
----- Original Message -----
From: "Hector Santos" <[email-masked]>

>> From: "Bruce Lilly" <[email-masked]>
>> For CBV, it means that acceptance by such a system's
>> MX host doesn't mean diddly.

> It implies one of four possibilities.
>
> - GOOD: ther you did a RCPT TO validation
> - BAD/GOOD: You are performing a delay validation (as you describe)
> - BAD: You are an open relay
> - BAD: You are a zombie (open relay)

There are another possibility that this thread picked up on specifically in
regards to the CBV concept with low timeout values

   - GOOD/BAD: Slow/Throttle Responsive System (Timeouts)

In regards to the CBV concept, this is probably only the "weakest spot"

Even Exim uses a lower timeout of 30 seconds.

As I mentioned a few times,  if this was significant issue, not 50%, 40%,
not even 1% but a 0.01% occurrence, I would seriously reconsider the CBV,
but not before exploring a possible solution.

I realize I am not Sendmail, just a small company. But enough spread of
customers, enough field testing, and production operations to determine as
an engineer what is practical or not, what is working or not, what is
problematic for customer support, etc.   For any customer, small or large,
getting even 1 false positives and complaints a day would be not only be
overwhelming in customer support cost, but completely unacceptable product
engineering. It would be pulled.

Finally, also consider that part of the solution (not just with CBV) is
everyone chipping in and doing their part too.  If there is one thing for
sure,  not just for us, but for everyone,  it has gotten people to clean up,
fix, correct and improve their system.   And that includes me too!!!  I have
found things I had to fix up, such as this MAIL FROM:SP<address> outbound
mail bug that crept in several revisions ago.   Never got any reports until
now with strict-rfc822 systems which is rare in regards to this space issue,
but nonetheless, a bug is a bug. It was fixed.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

From: "Hector Santos" <[email-masked]>
To: <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification
Date: Thu, 30 Jun 2005 17:02:32 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

----- Original Message -----
From: "Bruce Lilly" <[email-masked]>

>
> A check on a *random* mailbox has zero value because a client cannot
> tell whether a supposedly-random local part is or is not a valid
> mailbox on a remote system.

Bruce,

Lets put the CBV aside.

When you are considering "security" as we are today, will a MSA or MDA
accept an relay or route request for unauthorized sessions?

Theoritically, sure. Its possible. 100% and if you want to operate that way,
you could.

But in today's environment, it is considered a mode of operation that helps
spammers, especially the sorbig-based eVirus which emphasizes on open relay
or delay validation systems to exploit the bounce distribution.

Most system realize this and don't operate in this way.

Lets go to your system to see if you run a secured, non-open relay system:

220 mx02.mrf.mail.rcn.net ESMTP
helo hdev1
250 mx02.mrf.mail.rcn.net
mail from: <>
250 sender <> ok
rcpt to: <[email-masked]>
550 #5.1.0 Address rejected.
rcpt to: <[email-masked]>
550 #5.1.0 Address rejected.

No, you are secured. You dont' accept random address, but its is probably
because yo are only checking for local users and/or hosted domains.

> Nor can it tell if a supposedly-random
> domain name is also legitimately handled by the same MX host, at least
> not without doing a separate MX lookup or having equivalent out-of-band
> information.

I don't believe this matters Bruce.

Just like any MTA going to the MDA, or a MUA to a MSA, the CBV (MTA) is
going to the MDA to simulate the delivery of message at the mail host
responsible for the return path address.

If this unauthorized session CBV, MTA or what have you,  is allowed to
submit a non-local domain address, then this MDA is an open relay regardless
of how the system is operating with delay validation, and say, this is not
the operation the world desires due to the multi-billion cost in damages and
repercussions it has on the industry.

I don't dispute how a system can be configured to operate as you say, but an
unauthorized relay attempt is not the BCP.

I did learn one new trick that I think I will implement and explore - flip
it around, test the random address first.  If accept, it is operating in an
open relay behavior.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

From: "Hector Santos" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, "Tony Finch" <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification
Date: Thu, 30 Jun 2005 16:42:18 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

From: <[email-masked]>

> Indeed it does, since regardless of how desireable it may be to reject
invalid
> recipient addresses early, it most certainly is not required and is in
some
> cases next to impossible to implement.

Can you share the typical reasons you believe it impossible?

- Cost?
- Scalability?
- Legacy software?
- Slow Database I/O?
- Operating in Gateway modes?

In my view, these were all legitimate reasons, especially in the past.
Today, without a doubt, systems understand the importants in not promoting
bouce attacks.  We didn't originally offer dynamic SMTP level RCPT local
user validation.  It was done by the gateway and hence your accept+bounce
mode of operation.

But as the spam problem grew, coupled with the higher level of bad RCPT
attempts,  high bounce attacks, it became painfully obvious more control was
needed at the SMTP level.  So it was added, but as a default FALSE option as
to not surprise the sysops who were use to the old style UUCP/gateway mode
of operation.

When SORBIG hit in 2003, which emphasized on bounce-attacks as part of its
2nd level distribution process,  this is when we got huge support calls on
how to solve or reduce the high bounce volume. The answer was simple: "Turn
on the SMTP Local Recipient/Hosted Domain Validation" option.  The typical
response was: "Oh, I didn't know this option was there. Thanks."

> True enough, although hopefully the CBV system would be
> smart enough to tell the difference between "no such user foo"
> and "I think you smell and therefore I'm not accepting mail from
> you, never mind if the recipient address is valid or not".
>
> But getting all these details right is fairly tricky.

I believe what turned this thread around was the issues surrounding RCPT
limits for NULL return paths and how it was possible.  This was related to
the secondary RCPT random address test for an open relay performed by our
CBV implementation.

I don't think the details are not that tricky at all.

An CBV targets an MDA, the email domain host to simulate a validity of a
proper bounce process to the return path as required by RFC x821.

An MDA can be only operate in 3 modes in the CBV test:

1) Transaction level Forward Path validation
2) Post Transaction Forward Path validation
3) Open Relay (accepts all address, include remote)

Do you see any other?  In my last message to bruce, I cited 4, but the
zombie is basically behaving in open relay mode.

Now consider the POSSIBLE state results:

    MAIL FROM:<>
    RCPT TO:<return path>
    250 - ok
    or
    45x/55x - whatever reason.

A negative feedback is 100% deemed a trusted result.  Even Exim says the
same its callout description.  I don't believe there is any fuzziness here.

With the positive result, you have to decide if this is a OPEN RELAY and by
that I mean, it will accept any address.

So a second test is done to test the open relay:

    RCPT TO:<random non-local domain address>
    250 - ok
    or
    45x/55x - whatever reason.

The negative response code is what we are looking for.  The negative result
will pass the CBV test.   There is no fuzziness here.  This is a perfect
test with today's secured system with no pen relay behavior.

With the positive response code, we have now have what we call an open
relay.

Bruce correctly pointed out that this could be a delay validation system
that will accept any address.

I accept that, but the question is, will a system accept ANY random from an
unauthorized address.  I don't think so.  CBV or NO CBV,  the responsible
MSA system today require an authorized session to route mail.

So we ask, what is the purpose of the CBV?  To protect you from bad address,
and highly exploited open relay or zombie systems that will accept not just
any address, but specifically random addresses.

If we were sending a second address where only the local part changed, then
I would 100% agree that it proves nothing.  You could not reject this CBV
session.   But it is not a 2nd test for a random user at the same MDA. It is
random non-local domain address test which I hope you could address, the BCP
for a MSA will not accept unless you were authorized, especially with a NULL
return path address.

PS: I decided to contact/research the current CBV implementations/authors,
finished up the I-Ds I started which will include the CBV concept, among
others as well. I would love to get assistance from veteran RFC writers.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: Bounce/System Notification Address Verification
Date: Thu, 30 Jun 2005 15:58:02 -0400
Sender: [email-masked]

On Thu June 30 2005 15:02, Hector Santos wrote:

> This is why a good second RCPT TO: check on a random address has alot of
> value because it help detect which of the above the host is operation.

A check on a *random* mailbox has zero value because a client cannot
tell whether a supposedly-random local part is or is not a valid
mailbox on a remote system.  Nor can it tell if a supposedly-random
domain name is also legitimately handled by the same MX host, at least
not without doing a separate MX lookup or having equivalent out-of-band
information.

Now, some *specific* (i.e. not at all random) checks might yield some
information:
o permanent failure to accept "postmaster" for the domain indicates RFC
  ignorance (no further tests are likely to be useful)
o rejection of a syntactically-invalid mailbox is probably a good sign;
  conversely acceptance may simply mean that there's a catch-all
  mailbox
o acceptance for a mailbox having a domain known not to be handled by
  the MX may indicate an open relay; but open relays are not necessarily
  always evil
o rejection of a specific mailbox which appears in a specific message
  reverse path for which the host is a cognizant MX might indicate a
  problem -- but the problem might be in the site's configuration

> Systems which accept random address (non local domains) are not part of the
> solution. They are all intent and purpose open relays

Not necessarily; some hosts serve as MX for multiple domains -- that
is perfectly legitimate.

> and will most likely 
> get black listed in some DNS RBL site.

Considering that sites which operate no mail service at all tend to
get listed on blacklists, that doesn't say much about the sites; it
says something about blacklists, but that's another matter.

From: "Hector Santos" <[email-masked]>
To: <[email-masked]>
Cc: "Tony Finch" <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification
Date: Thu, 30 Jun 2005 15:45:46 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

Correction:

From: "Hector Santos" <[email-masked]>

> Now, consider the result codes.  Lets suppose you are not an open relay,
you
> are indeed a delay validation system.  In this case, you will get a
positive
> result code hence the CBV passes the test.
>
>     MAIL FROM:<>
>     250 OK
>     RCPT TO:<return-path>
>     250 OK
>     RCPT TO: <random address/domain>
>     55x User not found

That should be:

      55x Not Authorized to Relay mail
      or
      55x NULL can not relay mail

To match the idea that you are not an open relay.  "55x User not found"
would had implied you were doing a dynamic RCPT validation.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

From: [email-masked]
Cc: [email-masked], Tony Finch <[email-masked]>
To: Bruce Lilly <[email-masked]>
Date: Thu, 30 Jun 2005 11:49:55 -0700 (PDT)
Subject: Re: Bounce/System Notification Address Verification
Sender: [email-masked]

> On Thu June 30 2005 11:02, Tony Finch wrote:
> >
> > On Thu, 30 Jun 2005, Bruce Lilly wrote:
> > >
> > > Not necessarily; for better or worse, a number of sites use multiple
> > > MTA relays within their own administrative domain, and aliasing
> > > expansion might well occur at a separate upstream host from the one
> > > effecting actual delivery.  There is nothing particulary
> > > non-compliant about such a configuration, though it does have the
> > > characteristic of forcing a bounce where a single-host arrangement
> > > might be able to return an SMTO 5xx reply code
> >
> > There's nothing to prevent the front-end MX hosts in such a setup from
> > having access to the list of valid users,

> I suppose so, but then there's not much purpose in having such a split
> setup.

I have on many occasions found it very useful to have a backup MX on a
completely separate network that can accept mail when the primary network is
down or unreachable. And if it is possible to configure such a system to be
able to tell good addresses from bad for the domain, all the better since that
will lessen the amount of blow-back spam somewhat.

The mail servers for the innosoft.com domain were set up this way for many
years, as a matter of fact.

> My point, perhaps not clearly expressed, is that there are
> split setups that do expansion and validation downstream from the MX
> host(s), and that such a setup does tend to send bounces rather than
> 5xx reply codes.

Indeed. And while it is arguably better to do address checks on the front end
system, it certainly is not required, and may not even be possible in some
setups. And when it is possible the security implications are interesting, to
say the least.

This is why I pushed back on Pekka Savola's suggestion that
draft-hutzler-spamops-04.txt recommend/require this practice.

> Even that's not strictly necessary, as the MX could
> start a lock-step relay during RCPT TO rather than store-and-forward,
> but I don't know of any such split setups that work that way.

We use this sort of thing as part of large scale deployments that support
POP-before-SMTP, as a matter of fact. (Of course this effectively disjoint from
backup or secondary MX case.)

> > so it doesn't "force"
> > accept-and-bounce instead of reject.

> The point is that store-and-forward implies accept-and-bounce (except
> of course for a null reverse path).

Indeed it does, since regardless of how desireable it may be to reject invalid
recipient addresses early, it most certainly is not required and is in some
cases next to impossible to implement.

> What, you might ask, are the implications?  For one, it means collateral
> damage caused by such systems accepting joe-job spam then bouncing to
> the joe-job victim when the downstream host finally determines that
> there's no such recipient.  If you've received any such bounces, you
> may know that such system configurations are not uncommon.

I average around a hundred of these every day.

> For CBV, it
> means that acceptance by such a system's MX host doesn't mean diddly.
> And one generally can't tell from the outside if such a configuration
> is in use unless and until one analyzes a joe-job bounce from there.
> A secondary implication is that a CBV rejection from such a system
> probably means more about the CBV initiator than mailbox validity,
> and initiating a CBV session with such a host won't tell one much,
> unless perhaps one is trying to find bugs in one's less-than-100%
> compliant systems.

True enough, although hopefully the CBV system would be smart enough to tell
the difference between "no such user foo" and "I think you smell and therefore
I'm not accepting mail from you, never mind if the recipient address is valid
or not".
    
But getting all these details right is fairly tricky. Keith mentioned earlier
in this thread that an address verification specification would be a good idea.
I agree, and would be happy to assist in writing such a document.

				Ned

From: "Hector Santos" <[email-masked]>
To: <[email-masked]>
Cc: "Tony Finch" <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification
Date: Thu, 30 Jun 2005 15:02:42 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

From: "Bruce Lilly" <[email-masked]>

> The point is that store-and-forward implies accept-and-bounce (except
> of course for a null reverse path).
>
> What, you might ask, are the implications?  For one, it means collateral
> damage caused by such systems accepting joe-job spam then bouncing to
> the joe-job victim when the downstream host finally determines that
> there's no such recipient.  If you've received any such bounces, you
> may know that such system configurations are not uncommon.  For CBV, it
> means that acceptance by such a system's MX host doesn't mean diddly.

It implies one of four possibilities.

- GOOD: ther you did a RCPT TO validation
- BAD/GOOD: You are performing a delay validation (as you describe)
- BAD: You are an open relay
- BAD: You are a zombie (open relay)

If the remote host had any concern for today's issues, it will do an dynamic
validation.

Delay validation is no longer recommended, and open relays is a "MUST NOT"
operation today.

This is why a good second RCPT TO: check on a random address has alot of
value because it help detect which of the above the host is operation.

Systems which accept random address (non local domains) are not part of the
solution. They are all intent and purpose open relays and will most likely
get black listed in some DNS RBL site.

Now, consider the result codes.  Lets suppose you are not an open relay, you
are indeed a delay validation system.  In this case, you will get a positive
result code hence the CBV passes the test.

    MAIL FROM:<>
    250 OK
    RCPT TO:<return-path>
    250 OK
    RCPT TO: <random address/domain>
    55x User not found
    or
    55x Only 1 RCPT per NULL address

The CBV passes the test and the mail goes thru.

This has nothing to do with Multiple RCPT per NULL lines because that is
easily circumvented using a RSET.

The only issue is the idea of whether you believe an OPEN RELAY is still
valid today or not.  This had its usages in the past and probably even
today, but under an authorized session only.

In today's environment an unauthorized open relay behavior is not an
acceptable mode of operation today.  It causes too many problems such as
bounce attacks.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: Bounce/System Notification Address Verification
Date: Thu, 30 Jun 2005 14:12:09 -0400
Cc: Tony Finch <[email-masked]>
Sender: [email-masked]

On Thu June 30 2005 11:02, Tony Finch wrote:
> 
> On Thu, 30 Jun 2005, Bruce Lilly wrote:
> >
> > Not necessarily; for better or worse, a number of sites use multiple
> > MTA relays within their own administrative domain, and aliasing
> > expansion might well occur at a separate upstream host from the one
> > effecting actual delivery.  There is nothing particulary
> > non-compliant about such a configuration, though it does have the
> > characteristic of forcing a bounce where a single-host arrangement
> > might be able to return an SMTO 5xx reply code
> 
> There's nothing to prevent the front-end MX hosts in such a setup from
> having access to the list of valid users,

I suppose so, but then there's not much purpose in having such a split
setup.  My point, perhaps not clearly expressed, is that there are
split setups that do expansion and validation downstream from the MX
host(s), and that such a setup does tend to send bounces rather than
5xx reply codes.  Even that's not strictly necessary, as the MX could
start a lock-step relay during RCPT TO rather than store-and-forward,
but I don't know of any such split setups that work that way.

> so it doesn't "force" 
> accept-and-bounce instead of reject.

The point is that store-and-forward implies accept-and-bounce (except
of course for a null reverse path).

What, you might ask, are the implications?  For one, it means collateral
damage caused by such systems accepting joe-job spam then bouncing to
the joe-job victim when the downstream host finally determines that
there's no such recipient.  If you've received any such bounces, you
may know that such system configurations are not uncommon.  For CBV, it
means that acceptance by such a system's MX host doesn't mean diddly.
And one generally can't tell from the outside if such a configuration
is in use unless and until one analyzes a joe-job bounce from there.
A secondary implication is that a CBV rejection from such a system
probably means more about the CBV initiator than mailbox validity,
and initiating a CBV session with such a host won't tell one much,
unless perhaps one is trying to find bugs in one's less-than-100%
compliant systems.

Date: Thu, 30 Jun 2005 16:02:15 +0100
From: Tony Finch <[email-masked]>
To: [email-masked]
Subject: Re: Bounce/System Notification Address Verification
Sender: [email-masked]

On Thu, 30 Jun 2005, Bruce Lilly wrote:
>
> Not necessarily; for better or worse, a number of sites use multiple
> MTA relays within their own administrative domain, and aliasing
> expansion might well occur at a separate upstream host from the one
> effecting actual delivery.  There is nothing particulary
> non-compliant about such a configuration, though it does have the
> characteristic of forcing a bounce where a single-host arrangement
> might be able to return an SMTO 5xx reply code

There's nothing to prevent the front-end MX hosts in such a setup from
having access to the list of valid users, so it doesn't "force"
accept-and-bounce instead of reject.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.

From: "Hector Santos" <[email-masked]>
To: "william\(at\)elan.net" <[email-masked]>, "Matti Aarnio" <[email-masked]>
Cc: "Arnt Gulbrandsen" <[email-masked]>, <[email-masked]>
Subject: Strict RFC x821/x822 Checking [Re: Bounce/System Notification Address Verification]
Date: Thu, 30 Jun 2005 09:23:49 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

From: "william(at)elan.net" <[email-masked]>

> As far as anti-spam techniques what happens is that some percent of
> messages come directly from spammer controlled PCs and it appears some
> spam software indeed was designed to mimic those badly written MUAs
> and also do not work properly (or its possible that some spam software
> in fact directly tries to interface with those bad MUAs to send email
> out). So its exactly those MUA->MDA spam attempts that would be caught
> by such anti-spam technique.

Good observation. I need to study the percentages here.

As much as I am a stickler for standards (and of course, that include my own
software complying),  we need to seriously deal with backward compatibility.

So I would suggest that authorized sessions could be used as a way to deal
with non-compliant exemptions *specifically* in regards to the no-space
syntax.

At this moment, purely because of legacy issues, this one, needs to be less
strict.

But if the numbers at very high,  I agree with Arnt, that this would be very
good tag for a Bayesian weight.

It might be a good idea to outline all the SMTP x821 compliancy issues (red
flags) that one may face and discuss what is possible or not.

x821 level

1.0: HELO/EHLO domain literal  - no brackets
1.1. HELO/EHLO [domain literal] - ip mismatch
1.2: HELO/EHLO FQDN -  nxdomain
1.3: HELO/EHLO FQDN -  ip mismatch

2.0: MAIL FROM:sp<address> - illegal syntax
2.1. MAIL FROM:<address> - valid return path

3.0  RCPT TO:sp<address> - illegal syntax
3.1  RCPT TO:<multiple addresses> - limits per NULL return path
3.2  RCPT TO:<remote_address> - non-authorized sessions

x822 level

4.0  DATA  - 822 server, 2822 header
4.1  DATA  - 822 server, no headers
4.2  DATA  - 822 server, partial headers
4.4  DATA  - 2822 server, no headers
4.5  DATA  - 2822 server, partial headers
4.6  DATA  - SenderID/PRA (2822) server, no PRA

Others?

We can look at all the issues, whether ort not it is applicable,
recommendations for handling, etc.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

From: "Hector Santos" <[email-masked]>
To: "william\(at\)elan.net" <[email-masked]>, "Matti Aarnio" <[email-masked]>
Cc: "Arnt Gulbrandsen" <[email-masked]>, <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification
Date: Thu, 30 Jun 2005 08:51:48 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

----- Original Message -----
From: "william(at)elan.net" <[email-masked]>

> The point is to remember what standard specs say and
> not give in and allow for incorrect behavior just because
> one large vendor says so.

I agree. I'm all for strict compliancy. Including myself.

However, if a server is less strict (in regards to the MAIL FROM:sp) which
is a long time legacy issue, and allows for non-compliant behavior,  does
this make this just as non-compliant?

I mean, I can see the http://www.DNSREPORT.com  people adding a check for
this kind of strict testing.  It would be useful.

But I mean, your own server at elan.net didn't bother to validate the domain
literal.

220 sokol.elan.net ESMTP Sendmail 8.13.1/8.13.1;
        Thu, 30 Jun 2005 05:45:42 -0700
helo [216.151.192.200]
250 sokol.elan.net Hello adsl-10-44-25.mia.bellsouth.net
        [65.10.44.25], pleased to meet you

which is typically an illegal syntax due to being a spoof.

nor does check for a client domain local domain spoof as well:

220 sokol.elan.net ESMTP Sendmail 8.13.1/8.13.1;
        Thu, 30 Jun 2005 05:47:43 -0700
helo mail.elan.net
250 sokol.elan.net Hello adsl-10-44-25.mia.bellsouth.net
        [65.10.44.25], pleased to meet you

Again, another RFC violation because its not support to be your domain there
with my machine as the client.

So how far will we go with this?

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: Bounce/System Notification Address Verification
Date: Thu, 30 Jun 2005 08:14:13 -0400
Cc: "Robert A. Rosenberg" <[email-masked]>
Sender: [email-masked]

On Thu June 30 2005 01:46, Robert A. Rosenberg wrote:
> 
> At 08:02 -0400 on 06/29/2005, Bruce Lilly wrote about Re: 
> Bounce/System Notification Address Verification:

> >Return-Path: <>
> >To: [email-masked]
> >...
> >
> >which may well be expanded to multiple RCPT TO mailboxes.
> 
> ... at the receiving end AFTER reception. It comes in as ONE address 
> and when delivery is attempted, the message is cloned for delivery to 
> multiple addresses/mailboxes.

Not necessarily; for better or worse, a number of sites use multiple
MTA relays within their own administrative domain, and aliasing
expansion might well occur at a separate upstream host from the one
effecting actual delivery.  There is nothing particulary
non-compliant about such a configuration, though it does have the
characteristic of forcing a bounce where a single-host arrangement
might be able to return an SMTO 5xx reply code -- of course that's
the case for any multi-hop store-and-forward SMTP path; a reply
code w/o bounce generally only occurs when the sender directly
connects to the recipient's host as shown in RFC 821 Figure 1,
repeated in RFC 2822, with no intermediate relay(s) or gateway(s).

From: "Hector Santos" <[email-masked]>
To: "Matti Aarnio" <[email-masked]>, "Arnt Gulbrandsen" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification
Date: Thu, 30 Jun 2005 08:03:36 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

From: "Hector Santos" <[email-masked]>

> But now, what are really talking about here?
> 
> Strict RFC822 and/or RFC 2822 compliancy across the board?

Sorry, meant "RFC 821 and/or RFC 2821"

Hector Santos, Santronics Software, Inc.
http://www.santronics.com

Date: Thu, 30 Jun 2005 05:02:36 -0700 (PDT)
From: "william(at)elan.net" <[email-masked]>
To: Matti Aarnio <[email-masked]>
cc: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: Bounce/System Notification Address Verification
Sender: [email-masked]

On Thu, 30 Jun 2005, Matti Aarnio wrote:

> On Thu, Jun 30, 2005 at 11:03:50AM +0200, Arnt Gulbrandsen wrote:
>> Hector Santos writes:
>>> But the reason according to your server is the space in the MAIL FROM:
>>> <> command as a syntax error.
>>>
>>> Ok, wow!!!
>>>
>>> You better reconsider being more relaxed with that MAIL FROM: strict
>>> syntax I'm sure you will get hit by other servers
>>
>> In the past week, 100% of the mail arriving at work with
>>      MAIL FROM: <...
>> or
>>      RCPT TO: <...
>> was spam. Good fodder for bayesian analysis.
>>
>> (Btw, I didn't discover this; der Mouse told me.)

As far as I know all commonly used MTAs use correct syntax when sending 
mail out and so when email is transmitted from remote network it would
be fine. But it is also true that some SMTP-specs incompatible MUAs exist
that use "MAIL FROM: " so it might not be good idea to drop email from
local users who are trying to submit email if you know that those users
can't use any other MUAs.

As far as anti-spam techniques what happens is that some percent of
messages come directly from spammer controlled PCs and it appears some 
spam software indeed was designed to mimic those badly written MUAs 
and also do not work properly (or its possible that some spam software
in fact directly tries to interface with those bad MUAs to send email
out). So its exactly those MUA->MDA spam attempts that would be caught
by such anti-spam technique.

> I would have used strict-rfc822 mode in my work production systems,
> if it would not reject something like 95% of users who send thru their
> ISP master relays...

Its not RFC2822 at all. And its always been this way in email:

RFC772 (I think its first genuine RFC with MAIL FROM  - published in 1980)
on page 8 gives the following syntax:
  MAIL <SP> FROM:<sender> [<SP> TO:<path>] <CRLF>

RFC821 (published in 1982) in section 3.1 gives the following syntax:
  "MAIL <SP> FROM:<reverse-path> <CRLF>"

RFC2821 (published in 2001) gives the following syntax:
  "MAIL FROM:" ("<>" / Reverse-Path)
                        [SP Mail-parameters] CRLF
Reverse-path = Path
Path = "<" [ A-d-l ":" ] Mailbox ">"

> MS Outlooks do put those extra white-spaces in there blatantly..

Ok, so we find that Microsoft email software is not SMTP compliant in yet 
another way. Something new and unexpected? Don't think so!

The point is to remember what standard specs say and not give in and allow
for incorrect behavior just because one large vendor says so.

-- 
William Leibzon
Elan Networks
[email-masked]

From: "Hector Santos" <[email-masked]>
To: "Matti Aarnio" <[email-masked]>, "Arnt Gulbrandsen" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification
Date: Thu, 30 Jun 2005 08:01:16 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

From: "Matti Aarnio" <[email-masked]>

> On Thu, Jun 30, 2005 at 11:03:50AM +0200, Arnt Gulbrandsen wrote:

> I would have used strict-rfc822 mode in my work production systems,
> if it would not reject something like 95% of users who send thru their
> ISP master relays...
>
> MS Outlooks do put those extra white-spaces in there blatantly..
>
> At my own private system I use strict syntax processing, and those
> who can't send because of it, well..  tough.  However I can't do
> that for paying customers  :-(
>

Very true.

But now, what are really talking about here?

Strict RFC822 and/or RFC 2822 compliancy across the board?

If we begin to use this "MAIL FROM:sp" (and "RCPT TO:sp") syntax mite as a
strict reject in the name of spam or as a indicator for spam, then you also
apply the same consideration for other entities of the state machine.  We
can't pick one thing like this and skip all other considerations, such as
the example in my last message illustrating the HELO local domain spoofing.

Same with the Return Path.  This is required to be valid by RFC x821
standards.

Also,  what about DATA blocks with no headers in it?   Many servers accept
this and will use the envelope to fill in From:/To:.

Microsoft's SenderID/PRA will enforce 2822.  At HOTMAIL.COM,  if it can't
extract the PRA from the 2822 header, then the message is no good according
to the specs.  At hotmail.com, the message is accepted and goes into la-la
land.  No bounce, no other indication.

The PRA is:

      Resent-Sender
      Resent-From:
      Sender:
      From:

In that order, but the PRA also has logic for the group positions of the
headers, including Return-Path. I still don't see the reasoning behind it.
Microsoft calls it a "Complex" PRA lookup logic, so complex, its patented!

The problem, the first three are not required, and the From: can be assigned
the Mail From: if the data block is message.

So in short,  SenderID/PRA ignores the Mail From: when in fact, a good bit
of the time, over 80% based on my logs:

            2822.PRA  = 2821.MAIL FROM

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

From: "Hector Santos" <[email-masked]>
To: "Arnt Gulbrandsen" <[email-masked]>, <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification
Date: Thu, 30 Jun 2005 07:30:24 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

----- Original Message -----
From: "Arnt Gulbrandsen" <[email-masked]>

> Hector Santos writes:

> > You better reconsider being more relaxed with that MAIL FROM: strict
> > syntax I'm sure you will get hit by other servers
>
> In the past week, 100% of the mail arriving at work with
>      MAIL FROM: <...
> or
>      RCPT TO: <...
> was spam. Good fodder for bayesian analysis.
>
> (Btw, I didn't discover this; der Mouse told me.)

Interesting. Very interesting.

Well,  I'm little hot under the collar right now.  Apparently, two revisions
ago our wcSMTP outbound server introduced a space.  So we got a get a hotfix
out asap today for this mite.   But our inbound server has always allowed
for a space simply because it was always possible. It never rejected because
it had space. Claus's Sendmail "X.0.0.Alpha4.0" server/version is the first
time I've encountered such a restriction.

Does anyone have any historistical perspective on this?

Anyway, I did some log analysis on this and you're right; a good bit of the
transactions which "appeared" to be from spammers had spaces.  I also
noticed the Microsoft Outlook MUA also uses a space.

You're right. I might fit well in a bayesian analyzer.

Here's another one.  This is the SendMail.com server:

220 foon.sendmail.com ESMTP Sendmail Switch-3.1.7/Switch-3.1.7;
        Thu, 30 Jun 2005  03:55:50 -0700
helo smtp.sendmail.com
250 foon.sendmail.com Hello adsl-10-44-25.mia.bellsouth.net [65.10.44.25],
pleas
ed to meet you

See the problem?  [Hint: Spoofing]

Lets check Claus's esmtp.org server:

220 zardoc.esmtp.org ESMTP sendmail X.0.0.Alpha4.0
helo zardoc.esmtp.org
250 zardoc.esmtp.org Hi there
mail from: <>
501 5.1.7 Bad sender's mailbox address syntax.

Wonderful!  Its worry about a space, but it doesn't protect its own local
domains! <g>

On a good day, I catch about 12% of these at my server.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

Date: Thu, 30 Jun 2005 13:10:44 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Bounce/System Notification Address Verification
Cc: Matti Aarnio <[email-masked]>
Sender: [email-masked]

Matti Aarnio writes:
> I would have used strict-rfc822 mode in my work production systems, if 
> it would not reject something like 95% of users who send thru their 
> ISP master relays...
>
> MS Outlooks do put those extra white-spaces in there blatantly..

I think you'll find the world a little easier to deal with if you run 
outgoing relay and incoming MX on separate hosts. Your outgoing relays 
will then have to deal with Outlook and your incoming MXes will have to 
deal with spammers, random probes and other people's outgoing relays. A 
nice division of responsibility.

Ten or fifteen years ago some smart admin at EUnet told me it's better 
to run one service per host. I didn't understand why then. Now his 
advice seems very, very good.

Arnt

Date: 	Thu, 30 Jun 2005 13:42:36 +0300
From: Matti Aarnio <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked]
Subject: Re: Bounce/System Notification Address Verification
Sender: [email-masked]

On Thu, Jun 30, 2005 at 11:03:50AM +0200, Arnt Gulbrandsen wrote:
> Hector Santos writes:
> > But the reason according to your server is the space in the MAIL FROM: 
> > <> command as a syntax error.
> >
> > Ok, wow!!!
> >
> > You better reconsider being more relaxed with that MAIL FROM: strict 
> > syntax I'm sure you will get hit by other servers
> 
> In the past week, 100% of the mail arriving at work with
>      MAIL FROM: <...
> or
>      RCPT TO: <...
> was spam. Good fodder for bayesian analysis.
> 
> (Btw, I didn't discover this; der Mouse told me.)

I would have used strict-rfc822 mode in my work production systems,
if it would not reject something like 95% of users who send thru their
ISP master relays...

MS Outlooks do put those extra white-spaces in there blatantly..

At my own private system I use strict syntax processing, and those
who can't send because of it, well..  tough.  However I can't do
that for paying customers  :-(

> Arnt

-- 
/Matti Aarnio	<[email-masked]>

Date: Thu, 30 Jun 2005 11:03:50 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Bounce/System Notification Address Verification
Sender: [email-masked]

Hector Santos writes:
> But the reason according to your server is the space in the MAIL FROM: 
> <> command as a syntax error.
>
> Ok, wow!!!
>
> You better reconsider being more relaxed with that MAIL FROM: strict 
> syntax I'm sure you will get hit by other servers

In the past week, 100% of the mail arriving at work with
     MAIL FROM: <...
or
     RCPT TO: <...
was spam. Good fodder for bayesian analysis.

(Btw, I didn't discover this; der Mouse told me.)

Arnt

Date: Thu, 30 Jun 2005 09:18:04 +0100
From: Tony Finch <[email-masked]>
To: "Robert A. Rosenberg" <[email-masked]>
cc: [email-masked]
Subject: Re: Bounce/System Notification Address Verification
Sender: [email-masked]

On Thu, 30 Jun 2005, Robert A. Rosenberg wrote:

> ... at the receiving end AFTER reception. It comes in as ONE address and when
> delivery is attempted, the message is cloned for delivery to multiple
> addresses/mailboxes. As I stated, unless the expansion creates a list that has
> 2 or more addresses that are NOT handled by THIS SMTP Server, you get the same
> result as if all the addresses were listed in the original message. Only in
> the "2 or more addresses that are NOT handled by THIS SMTP Server" case can
> you end up with a message that is relayed with more than one RCPT-TO (with a
> MAIL-FROM of <>) and that only when 2 or more of these addresses are in the
> same domain (or at least have domains that map to the same MX server).

You appear to be violently agreeing.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.

From: "Hector Santos" <[email-masked]>
To: <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification
Date: Thu, 30 Jun 2005 02:09:43 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

From: "Claus Assmann" <[email-masked]>

> On Tue, Jun 28, 2005, Claus Assmann wrote:
>
> > On Tue, Jun 28, 2005, Hector Santos wrote:
>
> > > 20040311 14:35:45 C: MAIL FROM: <>
> > > 20040311 14:35:46 S: 250 2.5.0 Address Ok.
> > > 20040311 14:35:46 C: RCPT TO: <[email-masked]>
>
> > Why does your system send a space after the colon?
>
> Is this not worth an answer?

Sorry, I started it, put in my draft folder but forgot to get back to it.

I thougt you were talking about the above sonnection.nl host  as an
explanation or reason for the CBV failure at Rolf's site.  I checked that
and it was fine.  It didn't fail with the space.

> > Let's see whether your CBV still does that.
>
> It seems it does: the direct mail was not accepted:
>
> Recipient: <[email-masked]>
> Remote-MTA: 208.247.131.9
> Reason: 550 Return Path not verifiable.
>
> Well, the return path is just working fine (even sourceforge
> with its callback has no problem with it).

I see now you were talking about your own SendMail server at esmtp.org.

AFIK, no server freaks out with the space. But nonetheless, it is not
consistent with the 2821 RCPT TO ABNF.   I already updated our CBV for the
next update. Thanks for pointing it out.

Let me get your logs... for this address of yours?  [email-masked]  ???
The only thing I found for esmtp.org domain was this following log which is
our WCSAP processor run from WCSMTP:

20050629 00:08:53 version    : 2.01 / 1.62
20050629 00:08:53 calltype   : SMTP
20050629 00:08:53 state      : rcpt
20050629 00:08:53 cip        : 63.195.85.27
20050629 00:08:53 cdn        : zardoc.esmtp.org
20050629 00:08:53 from       : <[email-masked]>
20050629 00:08:53 rcpt       : <[email-masked]>
20050629 00:08:53 testorder  : FLT RBL SPF CEP CBV
20050629 00:08:54 sapfilter  : pass (time:78)
20050629 00:08:54 saprbl     : testing 27.85.195.63.sbl.spamhaus.org
20050629 00:08:54 saprbl     : testing 27.85.195.63.list.dsbl.org
20050629 00:08:54 saprbl     : testing 27.85.195.63.bl.spamcop.net
20050629 00:08:54 saprbl     : pass (time:266)
20050629 00:08:54 sapspf     : none (time:141)
20050629 00:08:54 sapcep     : test from=esmtp.org
20050629 00:08:54 sapcep     : test cdn=zardoc.esmtp.org
20050629 00:08:54 sapcep     : none (time:187)
20050629 00:08:54 sapcbv     : total mx records: 1
20050629 00:08:54 try mx     : zardoc.esmtp.org ip: 63.195.85.27
20050629 00:08:54 # connecting to 63.195.85.27
20050629 00:08:55 S: 220 zardoc.esmtp.org ESMTP sendmail X.0.0.Alpha4.0
20050629 00:08:55 C: NOOP WCSAP v2.01 Wildcat! Sender
                                Authentication Protocol
http://www.santronics.com
20050629 00:08:55 S: 250 2.0.0 Ok.
20050629 00:08:55 C: HELO mail.winserver.com
20050629 00:08:55 S: 250 zardoc.esmtp.org Hi there
20050629 00:08:55 C: MAIL FROM: <>
20050629 00:08:55 S: 501 5.1.7 Bad sender's mailbox address syntax.
20050629 00:08:55 sapcbv     : 501
20050629 00:08:55 result     : reject (0)
20050629 00:08:55 smtp code  : 550
20050629 00:08:55 reason     : Rejected by WCSAP CBV

If this session is yours, then it was CBV rejected due not honoring a NULL
mail from:

But the reason according to your server is the space in the MAIL FROM: <>
command as a syntax error.

Ok, wow!!!

You better reconsider being more relaxed with that MAIL FROM: strict syntax
I'm sure you will get hit by other servers

Unless you are saying this should be 100% honored and used for rejection?

I just ran a grep on May 2005 logs for incoming sessions looking for similar
syntax.

Out of 132,636 incoming transactions,  35360 transactions had a

            "MAIL FROM:sp<address>"

format.

Definitely use the standard for outgoing.   But parsing the space in
incoming messages is critical otherwise you will really get a lot of
rejections based on this.

Here are just three different servers out that accept the space.  You are
the first server that had this strict syntax problem.

Comcast.net

220 foon.sendmail.com ESMTP Sendmail Switch-3.1.7/Switch-3.1.7; Wed, 29 Jun
2005
 23:01:41 -0700
helo hdev1
250 foon.sendmail.com Hello adsl-10-44-25.mia.bellsouth.net [65.10.44.25],
pleas
ed to meet you
mail from: <>
250 2.1.0 <>... Sender ok

Sendmail.Com

220 sccrmxc16.comcast.net - Maillennium ESMTP/MULTIBOX sccrmxc16 #206
helo hdev1
250 sccrmxc16.comcast.net
mail from: <>
250 ok

Tony's EXIM machine

220-ppsw-0.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.140]:25) ESMTP Exim
4.51+ppsw+
3 Thu, 30 Jun 2005 07:03:15 +0100
220 This is the Electronic Mail Service of the Chancellor, Masters, and
Scholars
 of the University of Cambridge
helo hdev1
250 ppsw-0.csi.cam.ac.uk Hello adsl-10-44-25.mia.bellsouth.net [65.10.44.25]
mail from: <>
250 OK

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

Date: Thu, 30 Jun 2005 01:34:08 -0400
To: [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification
Sender: [email-masked]

At 07:54 -0400 on 06/29/2005, John C Klensin wrote about Re: 
Bounce/System Notification Address Verification:

>--On Wednesday, 29 June, 2005 00:50 -0400 Keith Moore
><[email-masked]> wrote:
>
>>>  I am not rejecting anything. All I am suggesting is that when
>>>  more than  one recipient is to be used for the message, to
>>>  generate a separate copy  for each recipient (with only that
>>>  recipient listed as the "To") so  there are separate copies
>>>  (as would occur with multi-recipient [messages  where each
>>>  recipient is in a different domain] at the MTA stage ).
>>
>>  Why should an MTA or MUA bother to do this?  This part of the
>>  SMTP standard has been stable since c. 1980 and it has _never_
>>  required this.
>>...
>>  spammers have consistently shown themselves to be very
>>  flexible at adapting to far more substantial countermeasures.
>>  and it's much easier for spammers to adapt than for the vast
>>  installed base to adapt.  it is counterproductive to impose
>>  meaningless restrictions on legitimate senders.  in the long
>>  term this only adds complexity and damages transparency of the
>>  mail system without doing anything to discourage spam.
>
>And, of course, going to one-recipient-per-message also vastly
>increases total transmission time for messages, especially
>moderately long messages, in normal use.  That total
>transmission time issue -- let's open a minimal number of TCP
>connections and transmit the payload on a target host basis, not
>a target user one-- is, of course, why the multiple RCPT
>provision was included in the mail specs more than a quarter of
>a century ago.

Since it is my comment being quoted, I'll respond. My suggestion is 
ONLY about Mail-From <> messages. These messages are (so far as I can 
tell) very short Payloads (under 1-2K) and since they will all be 
queued at the same time will flow back-to-back over the same 
MTA-to-MTA session (ie: No extra TCP/IP Setup/Teardown overhead). 
What automatic <> replies that support multiple recipients do you 
expect to exceed my 1-2K payload size? The "multiple RCPT
provision" was instituted for a problem that no longer exists (narrow 
pipes, long setup/teardown times, and slow transmissions). With the 
current speeds/bandwidth the extra traffic gets lost in the noise.

Date: Thu, 30 Jun 2005 01:46:28 -0400
To: [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification
Sender: [email-masked]

At 08:02 -0400 on 06/29/2005, Bruce Lilly wrote about Re: 
Bounce/System Notification Address Verification:

>On Wed June 29 2005 00:30, Robert A. Rosenberg wrote:
>>
>>  At 13:50 +0100 on 06/28/2005, Tony Finch wrote about Re:
>>  Bounce/System Notification Address Verification:
>
>>  >However if the return path might have been an alias which expands to more
>>  >than one address, and this can reslult in legitimate bounces with more
>>  >than one recipient.
>
>>  No it doesn't. The original message has ONE recipient (the alias) and
>>  gets delivered to it. At that point the alias gets expanded and
>>  creates a new message which is sent to each recipient. Unless 2 or
>>  more recipients are hosted at some domain other than the one where
>>  the alias is hosted, each copy is delivered directly to their mailbox
>>  (as if the message had arrived with all the addresses explicitly
>>  listed as RCPT-TOs).
>
>You might want to reread Tony's statement carefully.  Perhaps an
>example will help:
>
>Original message:
>Return-Path: [email-masked]
>...
>
>Bounce:
>Return-Path: <>
>To: [email-masked]
>...
>
>which may well be expanded to multiple RCPT TO mailboxes.

... at the receiving end AFTER reception. It comes in as ONE address 
and when delivery is attempted, the message is cloned for delivery to 
multiple addresses/mailboxes. As I stated, unless the expansion 
creates a list that has 2 or more addresses that are NOT handled by 
THIS SMTP Server, you get the same result as if all the addresses 
were listed in the original message. Only in the "2 or more addresses 
that are NOT handled by THIS SMTP Server" case can you end up with a 
message that is relayed with more than one RCPT-TO (with a MAIL-FROM 
of <>) and that only when 2 or more of these addresses are in the 
same domain (or at least have domains that map to the same MX server).

Date: Thu, 30 Jun 2005 01:17:56 -0400
To: [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification
Sender: [email-masked]

At 07:53 -0400 on 06/29/2005, Bruce Lilly wrote about Re: 
Bounce/System Notification Address Verification:

>On Wed June 29 2005 01:40, Robert A. Rosenberg wrote:
>
>>  There is only (as I've noted in a prior message) a flaw if when
>>  [a] CBV probes an ISP and that ISP CBVs back in response to the
>>  probe, [the first sysrem] instead of accepting the CBV probe and 
>>responding with
>>  a "Good Address" reply turns around and tries to CBV the other
>>  Server. It is the job of [...] CBV users [...] to recognize
>>  the addresses used with their CBV probes and not respond with a CBV
>>  probe when the address is used by another CBV system. You handle CBV
>>  probles triggered by your own in-flight CBV probes do not require
>>  your CBV code to recognize other user's CBV probe patterns (ie: you
>>  should just CBV respond to them).
>
>Then it is the responsibility of the (nonexistent?) specification
>authors to completely specify such behavior, and as this is clearly
>an interoperability issue which if ignored can result in damage to
>the mail system is needs to be specified with use of BCP 14 MUST or
>MUST NOT.

While I agree that when an RFC is written on how CBV should operate, 
this is not the intent of my comment. I was responding to the 
statement that CBV can introduce CBV loops if a CBV probe triggers a 
return CBV probe to validate the claimed address of the prober before 
it will return a Valid-Address/Invalid-Address response to the 
original probe.

My intent was to show that this ping-pong/loop behavior (if it 
occurs) is due to a broken CBV design. The checks that are done in 
response to a RCPT-TO (that involve doing a CBV before acknowledging 
the command) should first involve a sanity check on the supplied 
RCPT-TO to insure it is not the MAIL-FROM used for sending CBV 
Probes. Since it is easy to spot YOUR probe addresses but hard to 
spot every other CBV user's addresses, the check needs to be done 
when someone you are probing tries to probe you back before they 
respond to your original probe.

Date: Wed, 29 Jun 2005 21:11:26 -0700
From: Claus Assmann <[email-masked]>
To: [email-masked]
Subject: Re: Bounce/System Notification Address Verification
Mail-Followup-To: Claus Assmann <[email-masked]>, [email-masked]
Sender: [email-masked]

On Tue, Jun 28, 2005, Claus Assmann wrote:

> On Tue, Jun 28, 2005, Hector Santos wrote:

> > 20040311 14:35:45 C: MAIL FROM: <>
> > 20040311 14:35:46 S: 250 2.5.0 Address Ok.
> > 20040311 14:35:46 C: RCPT TO: <[email-masked]>

> Why does your system send a space after the colon?

Is this not worth an answer?

> Let's see whether your CBV still does that.

It seems it does: the direct mail was not accepted:

Recipient: <[email-masked]>
Remote-MTA: 208.247.131.9
Reason: 550 Return Path not verifiable.

Well, the return path is just working fine (even sourceforge
with its callback has no problem with it).

From: "Hector Santos" <[email-masked]>
To: <[email-masked]>, "Robert A. Rosenberg" <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification
Date: Wed, 29 Jun 2005 22:18:17 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

From: "Robert A. Rosenberg" <[email-masked]>

>>>  Valdis Wrote:
>>>
>>>  would allow a spammer to send you a MAIL FROM/RCPT TO on a
>>>  first connection, then once the callback shows up, use *that*
>>>  information to create what looks like a "callback to a callback",
>>>  but proceed to the DATA step. Whoops.. ;)

>> Hector asked:
>>You are going to have to explain that line of thought..

> Since we were talking about the Verizon CBV, that Mail From will be
> from <[email-masked] so the spammer will do his CBV
> to that address. The correct response (as I noted) by Verizon would
> be to send a "Valid Address" response back. If this was real CBV, the
> next step would be a QUIT (to drop the connection). Since we are
> seeing what would occur since we are a spammer, a DATA is sent
> instead. In that case, Verizon SHOULD respond by dropping the
> connection (or sending a rejection code reply and drop the connection
> if the next response is not QUIT or RSET).

Correct.

This is special alias CBV address specific for Verizon's CBV implementation
which will not allow the state flow to reach the DATA point.

But why would a spammer do this?

It doesn't have to.  Just issue the 250 response to this   "antispamxxxx"
alias check which is only done when the first NULL return path RCPT TO check
produces a negative response.

If MailPass uses the 250 as an accept, then the spammer passes the test. No
need to do the CBV on the "antispamxxxxx".

Right?

I don't know the full MailPass logic here.   I will like to find out what
the complete logic here.

Btw, is this a commercial product? I can't find any central place on the net
for this server.

I am trying to find my notes on another vendor that offers an API for CBV,
but what I found interesting with this one is how it uses NOOP with session
hash values.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

From: "Hector Santos" <[email-masked]>
To: "Tony Finch" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification
Date: Wed, 29 Jun 2005 22:16:09 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

----- Original Message -----
From: "Tony Finch" <[email-masked]>
To: "Hector Santos" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, June 29, 2005 3:18 PM
Subject: Re: Bounce/System Notification Address Verification

>
> On Tue, 28 Jun 2005, Hector Santos wrote:
> >
> > Ok, at 44 seconds, it became the CBV, as you can see thre wasn't a
response
> > to the RCPT TO:   The timeout appears to be  35 seconds.
>
> That's way too short for a CBV timeout, and in any case the appropriate
> response to a timeout is 4xx (or perhaps 2xx), certainly not 5xx.

Tony,

When I first started our WCSAP system with the CBV feature in 2003,  I
reseachd other similar systems in place.  I found an old Dec/2003 file on my
drive that I saved clipped from Exim documentation regarding its Callout
feature.  I have the whole Exim Callout section below.  But here are the
highlights/questions.

| 37.15. Additional parameters for callouts,
|
| The default is 30 seconds. The timeout is used for each response from
| the remote host.

I don't recall if I decided to use 35 seconds based on Exim's 30 seconds.
But off hand, it reflects the default Windows socket timeout value.

| 37.14. Callout verification
|
| For a recipient address, the MAIL command contains the sender address of
| the incoming message. If the response to the RCPT command is a 2xx code,
| the verification succeeds. If it is 5xx, the verification fails. For any
| other condition, Exim tries the next host, if any.

We tried this next host idea for a timeout and found in cases where there
was a timeout, which was usually all the time,  the spammers exhibited the
intentional noresponsive behavior.   So imagine a spammer with 3-4 host,
and each will fail with the Exim 30 second timeout., we have a 90-120 delay
in the SMTP session creating scalability issues.

As I said, the false postive is the exception, not the rule,  so currently a
timeout on the responses (not the connection, or a busy response at the
greeting) will reject the session.

I am going to reexplore this and maybe just add more options here:

    CBVCommand.Timeout                             45     // new default
    CBVCommand.Timeout.ResponseCode      451   // explore new default
    CBVCommand.Timeout.TryNextHost          True  // explore new default

| If there is a problem
| with all the remote hosts, the ACL yields ``defer'', unless the defer_ok
| parameter of the callout option is given, in which case the condition is
| forced to succeed.

Can you explain the key difference between "defer" and "defer_ok"?

What does "forced to succeed" mean?

Regarding the "Postmaster" and "random" test it offers, it says:

| The idea here is to try to determine whether the remote host accepts all
| local parts without checking. If it does, there is no point in doing
| callouts for specific local parts. If the ``random'' check succeeds, the
| result is saved in a cache record, and used to force the current and
| subsequent callout checks to succeed without a connection being made,
| until the cache record expires.

The problem with this is its not doing a random domain,  just a random local
part.  By far, due to spam problem awareness with Open Relays,  only bad or
poorly setup systems keep these open.  Even if its a "good guy,"  this poor
setup plays into the hands of bounce attacks.  So it better to reject these
transactions.  Of this is my technical opinion for protecting a system.

However,  can you explain the postmaster usage?

As you know, this can cause a loopback.  Who ever ask me why we have an
option to skip postmaster return paths, this is why.   Although it only
causes 1 extra CBV,  by RFC 2821 requirements to accept all RCPT
<postmaster> commands, a CBV to validate a postmaster is a waste of time.
So we skip it for backward compatibility reasons.

Comments?

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

 --------------------------
Exim
37.14. Callout verification

For non-local addresses, routing verifies the domain, but is unable to
do any checking of the local part. There are situations where some means
of verifying the local part is desirable. One way this can be done is to
make an SMTP callback to the sending host (for a sender address) or a
callforward to a subsequent host (for a recipient address), to see if
the host accepts the address. We use the term callout to cover both
cases. This facility should be used with care, because it can add a lot
of resource usage to the cost of verifying an address. However, Exim
does cache the results of callouts, which helps to reduce the cost.
Details are in the next section.

A successful callout does not guarantee that a real delivery to the
address would succeed; on the other hand, a failing callout does
guarantee that it would fail.

If the callout option is present on a condition that verifies an
address, a second stage of verification occurs if the address is
successfully routed to one or more remote hosts. The usual case is
routing by a dnslookup or a manualroute router, where the router
specifies the hosts. However, if a router that does not set up hosts
routes to an smtp transport with a hosts setting, the transport's hosts
are used. If an smtp transport transport has hosts_override set, its
hosts are always used, whether or not the router supplies a host list.

When a host list is available, Exim makes SMTP connections to the remote
hosts, to test whether a bounce message could be delivered to a sender
address, or whether the current message could be delivered to a
recipient address. For a sender address, it sends:

  HELO <primary host name>
  MAIL FROM:<>
  RCPT TO:<the address to be tested>
  QUIT

For a recipient address, the MAIL command contains the sender address of
the incoming message. If the response to the RCPT command is a 2xx code,
the verification succeeds. If it is 5xx, the verification fails. For any
other condition, Exim tries the next host, if any. If there is a problem
with all the remote hosts, the ACL yields ``defer'', unless the defer_ok
parameter of the callout option is given, in which case the condition is
forced to succeed.

For SMTP callout connections, the port to connect to and the outgoing
interface are taken from the transport to which address was routed, if
it is a remote transport. Otherwise port 25 is used, and the interface
is not specified.

37.15. Additional parameters for callouts

The callout option can be followed by an equals sign and a number of
optional parameters, separated by commas. For example:

  verify = recipient/callout=10s,defer_ok

The old syntax, which had callout_defer_ok and check_postmaster as
separate verify options, is retained for backwards compatibility, but is
now deprecated. The additional parameters for callout are as follows:

<a time>: This specifies the timeout that applies for the callout
          attempt to each host. For example:

  verify = sender/callout=5s

The default is 30 seconds. The timeout is used for each response from
the remote host.

defer_ok: Failure to contact any host, or any other kind of temporary
          error is treated as success by the ACL. However, the cache is not
          updated in this circumstance.

no_cache: The callout cache is neither read not updated.

postmaster: A successful callout check is followed by a similar check
   for the local part postmaster at the same domain. If this address is
   rejected, the callout fails. The result of the postmaster check is
   recorded in a cache record; if it is a failure, this is used to fail
   subsequent callouts for the domain without a connection being made,
   until the cache record expires.

random: Before doing the normal callout check, Exim does a check for a
``random'' local part at the same domain. The local part is not really
random - it is defined by the expansion of the option
callout_random_local_part, which defaults to

  $primary_host_name-$tod_epoch-testing

The idea here is to try to determine whether the remote host accepts all
local parts without checking. If it does, there is no point in doing
callouts for specific local parts. If the ``random'' check succeeds, the
result is saved in a cache record, and used to force the current and
subsequent callout checks to succeed without a connection being made,
until the cache record expires.

37.16. Callout caching

Exim caches the results of callouts in order to reduce the amount of
resources used, unless you specify the no_cache parameter with the
callout option. A hints database called ``callout'' is used for the
cache. Two different record types are used: one records the result of a
callout check for a specific address, and the other records information
that applies to the entire domain (for example, that it accepts the
local part postmaster).

When an original callout fails, a detailed SMTP error message is given
about the failure. However, for subsequent failures use the cache data,
this message is not available.

The expiry times for negative and positive address cache records are
independent, and can be set by the global options
callout_negative_expire (default 2h) and callout_positive_expire
(default 24h), respectively.

If a host gives a negative response to an SMTP connection, or rejects
any commands up to and including

  MAIL FROM:<>

any callout attempt is bound to fail. Exim remembers such failures in a
domain cache record, which it uses to fail callouts for the domain
without making new connections, until the domain record times out. There
are two separate expiry times for domain cache records:
callout_domain_negative_expire (default 3h) and
callout_domain_positive_expire (default 7d).

Domain records expire when the negative expiry time is reached if callouts
cannot be made for the domain, or if the postmaster check failed. Otherwise,
they expire when the positive expiry time is reached. This ensures that, for
example, a host that stops accepting ``random'' local parts will eventually
be noticed.

The callout caching mechanism is based entirely on the domain of the address
that is being tested. If the domain routes to several hosts, it is assumed
that their behaviour will be the same.

37.17. Sender address verification reporting
When sender verification fails in an ACL, the details of the failure are
given as additional output lines before the 550 response to the relevant
SMTP command (RCPT or DATA). For example, if sender callout is in use, you
might see:

  MAIL FROM:<[email-masked]>
  250 OK
  RCPT TO:<[email-masked]>
  550-Verification failed for <[email-masked]>
  550-Called:   192.168.34.43
  550-Sent:     RCPT TO:<[email-masked]>
  550-Response: 550 Unknown local part xyz in <[email-masked]>
  550 Sender verification failed

If more than one RCPT command fails in the same way, the details are given
only for the first of them. However, some administrators do not want to send
out this much information. You can suppress the details by adding
``/no_details'' to the ACL statement that requests sender verification. For
example:

  verify = sender/no_details

From: "Hector Santos" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: CBV in the real world (was Re: Bounce/System Notification Address Verification) 
Date: Wed, 29 Jun 2005 20:07:09 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

From: <[email-masked]>

On Wed, 29 Jun 2005 08:30:08 EDT, Hector Santos said:

> 1) Considering the fact you were having bandwidth issues
> with your RBL setup, this is a clear corrective manner on
> your end.  For example,  decreasing your own socket
> timeouts for your RBL lookups.

> Now you're trying to tell Rolf what he has to do to make
> your mail server work.

No.  But if one wants to be part of the solution, it has to be a community
effort.  That's a general statement.

Just consider yourself.  You use PGP/MINE and a vary large percentage of the
world population has to go thru the extra steps to be able to read your
mail.   For me, your mail comes in as attachments.

But I understand. You know better, blame the other guys software and
everyone else should change to accommodate you.    No problem with that
feeling. I can understand it.  Just realize the hypocrisy in your targeted
statements.

Thanks Valdis!  You're the man! <g>

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

From: "Hector Santos" <[email-masked]>
To: "Tony Finch" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification
Date: Wed, 29 Jun 2005 19:58:34 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

From: "Tony Finch" <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification

> > Ok, at 44 seconds, it became the CBV, as you can see thre wasn't a
response
> > to the RCPT TO:   The timeout appears to be  35 seconds.
>
> That's way too short for a CBV timeout, and in any case the appropriate
> response to a timeout is 4xx (or perhaps 2xx), certainly not 5xx.
>
> In my experience using CBV for nearly a year, it is a very troublesome
> technique, and I'm still not happy with it. This is mainly because I don't
> have the patience to try to teach the world how to send well-formed email
> and fix their broken setups.

Finally!

Someone with some real CBV style operational experience with some
justifiable feedback I can have "faith" on.  I appreciate the feedback.

Would it be possible to share some logs?  [NDA ok by me]

I can certainly change the default for the timeout and I am going to pencil
in a revisit to a temporary response code. This was explored - no doubt.

Would it be fair to say you are in an academic environment?  Are you basing
your experience on customer support of their usage of Exim as well?

I am a firm believer of the social network concept.  Everyone is a social
network.  Everyone has their own special relationships and pattern of users.
And it is for this reason why each of us have different experiences.
Generalization helps, but backgrounds are important as well.

This is important because one of the fundamental generic premise behind the
CBV and I can't stress it enough.

     - It is based on the fundamental RFC x821 requirement of a
       WORKING return path.

That is the EXPLOIT of the Spamming World.  They rely on the broken systems,
the frustrations it presents, the administrators who back down.

We will never be able to solve the spammer problem if we persist with the
attitude that we should the continue to cater the operations of broken
systems.

With that said,  if the system is broken, it isn't getting by the return
path validator.

The undisputable fact is our commercial and customer experiences has been
met with extreme success, and  this is based on the strong compliancy
requirement.  This was the goal and when applied, with complete disregard
for user intentions,  it has prove a extreme majority of all transactions
are bad with very little false positive.

Of course, the admin has all the ability to turn it off so I will have to
get new feedbacks to find out more since the last major field testing was
done.  Hey,  a good bit of the sysops turned it off.   :-)   I can tell you
that many did early on when they first got the update and saw some emails
not coming in.   But for the most part, most realize the need to strengthen
the operations provided a much higher payoff over allowing tons of spam into
their system.   Without a doubt, this was most common experience.  Also, we
stress to customers to establish their social networks (white list, black
list), use SPF, etc to help in reducing the overhead and any false
positives.

Finally, back to the timeout.  I will most definitely revisit it, but I
should point out that any timeout CBV sessions has definitely been
attributed to bad sites.  Rolf was only a false positive because he reported
the problem.   Bad spammers do no report problems.  Rolf also fixed his
system and not allowing a slow RBL break communications.  That's not to
blame him.  I take full blame for this false positive.  No one needs to tell
me that.  But the solution to the spam problem is a community effort, not
just one sided. So as such, this is definitely not a situation where you
throw out the baby with the bath water.

If this is the going to be prevailing attitude in the IETF arena, I doubt
2821bis/2822bis will do any justice for anyone.  Just imagine when
SenderID/PRA is widely adopted in the internet.  Never mind the enforcement
of 2822 and incompatible systems. As I predict, hackers will blast huge
payloads just to frustrate the hell of administrators enough to create new
scalability issues and to disable SenderId/PRA.

Thanks for your feedback Tony.

If you want to go off list and compare logs, that would be great.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

Date: Wed, 29 Jun 2005 16:43:27 -0400
To: <[email-masked]>
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification
Sender: [email-masked]

At 15:20 -0400 on 06/28/2005, Hector Santos wrote about Re: 
Bounce/System Notification Address Verification:

>  > to do so
>>  would allow a spammer to send you a MAIL FROM/RCPT TO on a
>>  first connection, then once the callback shows up, use *that*
>>  information to create what looks like a "callback to a callback",
>>  but proceed to the DATA step. Whoops.. ;)
>
>You are going to have to explain that line of thought..
>
>Spammers starts a session:
>
>      MAIL FROM: <spammer>
>      RCPT TO: <local user>
>
>CBV is started before RCPT TO response is issued:  At the spammer host:
>
>      MAIL FROM: <>
>      RCPT TO: <spammer>
>
>What happens now?  Spammer does a call back to where?

Since we were talking about the Verizon CBV, that Mail From will be 
from <[email-masked] so the spammer will do his CBV 
to that address. The correct response (as I noted) by Verizon would 
be to send a "Valid Address" response back. If this was real CBV, the 
next step would be a QUIT (to drop the connection). Since we are 
seeing what would occur since we are a spammer, a DATA is sent 
instead. In that case, Verizon SHOULD respond by dropping the 
connection (or sending a rejection code reply and drop the connection 
if the next response is not QUIT or RSET).

Date: Wed, 29 Jun 2005 20:18:15 +0100
From: Tony Finch <[email-masked]>
To: Hector Santos <[email-masked]>
cc: [email-masked]
Subject: Re: Bounce/System Notification Address Verification
Sender: [email-masked]

On Tue, 28 Jun 2005, Hector Santos wrote:
>
> Ok, at 44 seconds, it became the CBV, as you can see thre wasn't a response
> to the RCPT TO:   The timeout appears to be  35 seconds.

That's way too short for a CBV timeout, and in any case the appropriate
response to a timeout is 4xx (or perhaps 2xx), certainly not 5xx.

In my experience using CBV for nearly a year, it is a very troublesome
technique, and I'm still not happy with it. This is mainly because I don't
have the patience to try to teach the world how to send well-formed email
and fix their broken setups.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.

To: Hector Santos <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: CBV in the real world (was Re: Bounce/System Notification Address Verification) 
From: [email-masked]
Date: Wed, 29 Jun 2005 13:29:03 -0400
Sender: [email-masked]

--==_Exmh_1120066143_16560P
Content-Type: text/plain; charset=us-ascii

On Wed, 29 Jun 2005 08:30:08 EDT, Hector Santos said:

> > The lessons of this example are two-fold:
> >
> >    1. CBV significantly contributes to the load of SMTP connections
> >       because the CBV itself initiates all sorts of verifications (like
> >       SPF, CSV, DNS domain verify, DNS BL's, static IP BL's, CBV itself
> >       in a loopback scenario etc.) and as such decreases the reliability
> >       of mail delivery.
> 
> hmm, a good generalized statement, but CBV runs on its own. You can't
> control what others will have.

Right.  And after having made this realization, you then promptly forget it:

> 1) Considering the fact you were having bandwidth issues with your RBL
> setup, this is a clear corrective manner on your end.  For example,
> decreasing your own socket timeouts for your RBL lookups.

Now you're trying to tell Rolf what he has to do to make your mail server
work.

--==_Exmh_1120066143_16560P
Content-Type: application/pgp-signature

--==_Exmh_1120066143_16560P--

Date: Wed, 29 Jun 2005 16:58:23 +0100
To: Keith Moore <[email-masked]>, Hector Santos <[email-masked]>
From: Paul Smith <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification
Cc: [email-masked]
Sender: [email-masked]

At 15:35 29/06/2005, Keith Moore wrote:
Fair statement, but I contest the >50% simply because that will imply at
>>least 49% of all CBV sessions would fail due to a 35 timeout which is
>>clearly not the case.
>
>you were the one that said majority.  majority means more than half.
>
>in my experience something like 1% of CBV sessions fail due to a 60 second 
>timeout.  and the failures aren't randomly distributed - the same domains 
>keep failing over and over. but it's important to deliver mail from those 
>people.
>
>if you're going to do CBV you need to do the same things that an MTA would 
>do in trying to deliver mail to an address, before declaring the address 
>to be invalid.  this implies not only implementing the single-session SMTP 
>timeouts but also being persistent in your attempts to validate the 
>address (so that a brief network or server outage doesn't make the address 
>appear invalid)
>
>yes, this is a performance issue, but you might be able to finesse it with 
>a cache. e.g.

Personally, I'd say that something like CBV should probably treat a failure 
such as a timeout or a 4xx SMTP error (eg 'mailbox full') as a (possibly 
non-cached) pass. Only a 5xx failure should be treated as indicating that 
the email address is incorrect.

CBV is such a 'vague' test that treating a temporary failure as a sign of a 
bad email address would be too pessimistic.

At the worst case, this would let through a bit of spam. Its far worse to 
block non-spam than it is to let through spam, so the safe 'failure' mode 
is to treat temporary failures as passes.

If the CBV checking MTA is timing out too soon and letting through too much 
spam, then it's simply up to the administrator of that to increase their 
timeout if they wish. I really can't see any other way of doing it. CBV 
can't set a performance requirement on other SMTP servers that is other 
than that specified in RFC 2821

Paul                            VPOP3 - Internet Email Server/Gateway
[email-masked]                      http://www.pscs.co.uk/

From: "Hector Santos" <[email-masked]>
To: "Keith Moore" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification
Date: Wed, 29 Jun 2005 11:53:59 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

From: "Keith Moore" <[email-masked]>

> in my experience something like 1% of CBV sessions fail due to a 60 
> second timeout.  

Based on your public statements,  I have zero faith in your experience.

Have a good one.

-- 
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

Date: Wed, 29 Jun 2005 10:35:46 -0400
From: Keith Moore <[email-masked]>
To: Hector Santos <[email-masked]>
Cc: [email-masked]
Subject: Re: Bounce/System Notification Address Verification
Sender: [email-masked]

>>nope.  what I'm implying is that the inability to verify a return
>>address via SMTP within 35 seconds is a poor criterion for failing to
>>deliver a message.  yes, the _majority_ (> 50%) of verifications will
>>complete in this time, but we need email to work a lot more often than
>>50% of the time.
> 
> 
> Fair statement, but I contest the >50% simply because that will imply at
> least 49% of all CBV sessions would fail due to a 35 timeout which is
> clearly not the case.

you were the one that said majority.  majority means more than half.

in my experience something like 1% of CBV sessions fail due to a 60 
second timeout.  and the failures aren't randomly distributed - the same 
domains keep failing over and over. but it's important to deliver mail 
from those people.

if you're going to do CBV you need to do the same things that an MTA 
would do in trying to deliver mail to an address, before declaring the 
address to be invalid.  this implies not only implementing the 
single-session SMTP timeouts but also being persistent in your attempts 
to validate the address (so that a brief network or server outage 
doesn't make the address appear invalid)

yes, this is a performance issue, but you might be able to finesse it 
with a cache. e.g.

first smtp session from sender:

 >>> MAIL FROM:<[email-masked]>
(server checks CBV cache, if not found, starts asynchronous CBV process)
<<< 250 <[email-masked]>
 >>> RCPT TO:<[email-masked]>
<<< 250 <[email-masked]>
 >>> DATA
(wait for up to N seconds for CBV to complete, then if not completed...)
<<< 421 CBV timeout, closing transmission channel

...which causes sender to retry later.
second smtp session from sender:

 >>> MAIL FROM:<[email-masked]>
(server checks CBV cache, finds the entry)
<<< 250 <[email-masked]>
 >>> RCPT TO:<[email-masked]>
<<< 250 <[email-masked]>
 >>> DATA
<<< 354 start mail input
 >>> (message followed by .)
etc.

the assumption here is that you're willing to try a CBV up to as often 
as the sender is willing to try to send you the message, and if any of 
those CBVs succeeds then you'll consider that address valid for a 
reasonable amount of time.  but the CBV's have to honor the SMTP 
timeouts.  really you should never treat a single timed out CBV attempt 
as an indication of a bad address - the address is only bad if the SMTP 
server says it is, or if you are unable to talk to its SMTP server for 
several days.

>>really, one failure in ten thousand legitimate
>>messages is too high...we should be able to achieve one failure in a
>>hundred thousand messages or better.
> 
> 
> Is this a standard criteria for acceptance?    If so, our statistics meet
> this criteria.

based on your public statements, I have zero faith in your ability to 
measure such things accurately.

Keith

Date: Wed, 29 Jun 2005 15:35:22 +0100
From: Tony Finch <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: CBV (does it really mean Call Back validation?)
Sender: [email-masked]

On Wed, 29 Jun 2005 [email-masked] wrote:
>
> And the big question off course:
> Does it stop spam?

It's good for dealing with badly forged junk, or junk sent from an
account which has been disabled. The downside is that there are a lot of
incompetent people sending email using invalid addresses or badly
configured scripts on web servers, etc. etc. plus the enormous number of
sites that block all MAIL FROM:<>.

Your idea of an ESMTP service extension for CBV could be worth doing.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.

To: Hector Santos <[email-masked]>, "John C Klensin"  <[email-masked]>, <[email-masked]>
From: [email-masked]
Subject: CBV (does it really mean Call Back validation?)
Date: Wed, 29 Jun 2005 15:21:03 +0100
Sender: [email-masked]

Let me start by saying that I like the CBV idea, but also see (at least one) problem with it.

But reflecting on the problem, Lets call it Reverse CBV (RCBV) it is solvable. without using the the MailFrom <> option, an option wich I dislike. (This is a personal opinion)

RCBV could be better solved as the two of the two (or tree!) parties involved knew that they where using CBV, wich means there

A: Should be an SMTP  keyword to indicate that the server might use CBV
B: the Client that does the CBVtest  needs to be CBV-aware.
C: The CBV-aware client MUST respond to this keyword. and so prevent looping
D: A B and C don't validate CBV, so there need to be more...

This solution requires an RFC and lets work (together??) on this basis.
Let persons who are pro-CBV make a Internet Draft, let the opponents shoot holes in it, let the pro-CBV  close the holes, ect, ect,
And at the end.
We (We are the internet) have good reasons why CBV is bad or we have an CBV-RFC that can used   within SMTP.

Ps this solution only solves the RCBV problem, does anybody see other problems with CBV?

And the big question off course:
Does it stop spam?

I recognise the problem that this can double or even quadripple the number of SMTP-connections if everybody starts using it, but even then I am wondering, if CBV stops 80% UBE will it not decrease the total number of SMTP connections.

Date: Wed, 29 Jun 2005 15:44:11 +0200
From: "Rolf E. Sonneveld" <[email-masked]>
Subject: Re: CBV in the real world (was Re: Bounce/System Notification Address Verification)
To: Hector Santos <[email-masked]>
Cc: [email-masked]
Reply-to: [email-masked]
Organization: Sonnection B.V.
Sender: [email-masked]

>>.... Due to
>>bandwidth problems the two or three DNS BL checks may have taken more
>>time than the 35 seconds you grant them.
>>    
>>
>
>You should consider a performance RBL site switcher based on fast/slow
>algorytm.  Move the fastest to the top, slowest to the bottom.  Works really
>well when one of the sites is down.
>  
>

Exactly what I said: you assume all SMTP systems will be adjusted to 
support your CBV setup.

>>The lessons of this example are two-fold:
>>
>>   1. CBV significantly contributes to the load of SMTP connections
>>      because the CBV itself initiates all sorts of verifications (like
>>      SPF, CSV, DNS domain verify, DNS BL's, static IP BL's, CBV itself
>>      in a loopback scenario etc.) and as such decreases the reliability
>>      of mail delivery.
>>    
>>
>
>hmm, a good generalized statement, but CBV runs on its own. You can't
>control what others will have.
>  
>

Right. You can't control, but you have to take it into account.

>>   2. To operate in the real world, CBV would at least have to implement
>>      the SMTP timeouts as specified in 2821.
>>    
>>
>
>Totally disagree with you here.  Again, it is a real-world case situation
>only which is the exception, not the rule.  Most systems are design to run
>fast.
>
>If this is required, the CBV is no longer valid and this isn't going to
>happen based on this timeout issue..  But more importantly, the numbers
>clearly do not back this up.
>  
>

I fail to see why CBV would no longer be 'valid'. If CBV does not work 
using SMTP timeout values, it has no right to exist. And I'm afraid you 
are the only one who think your numbers give a correct representation of 
reality. When you count the number of false positives based upon the 
number of complaints you get, you should think a moment about the number 
of mail admins which will not complain, and about the number of mail 
admins who will not be able to correctly to diagnose this problem (and 
hence will not report), or the number of mail admins who will not be 
able to send a complaint/report to you because of your CBV system...

>Remember who you are talking about: Bad systems. Not Good systems.  Good
>systems work well.  Bad systems do not. Bad systems do not. Good systems
>complains, like you did.
>  
>

Right. So what about systems on slow satellite links? What about network 
bandwidth in the developing countries? Should we exclude Africa from the 
Internet to be able to use CBV? Should we call systems in Bangladesh 
'Bad systems' because they lack the proper Internet access, or they only 
have intermittent access to the Internet?

>Besides, there are other considerations and ideas to solve this problem.
>
>1) Considering the fact you were having bandwidth issues with your RBL
>setup, this is a clear corrective manner on your end.  For example,
>decreasing your own socket timeouts for your RBL lookups.
>  
>

So to guarantee the succes of your CBV system, not only SMTP timeouts 
are minimized, but other people should decrease their DNS (socket) 
timeouts as well. Really, you're gonna change the world.

[...]

>Sorry, increasing the CBV timeout to SMTP specified levels, isn't going to
>happen. I might increase it to a new default value, but ultimately it is a
>sysop configuration item.
>  
>

Right, sysop configurable, but with the minimum values of 2821.

>On a similar note, I am considering bringing up a  recommendation for
>2821bis to consider reducing yesterday's legacy timeout values or atleast
>revisit a new fine tuning for today higher bandwidths.  But it really isn't
>a big deal.
>
>  
>
>>I see no reason why your SMTP client implementation would stick to the
>>2821 timeouts, while your CBV implementation would not. In both
>>situations the transport is the same.
>>    
>>
>
>Thats because you are writing the software to interface with other systems
>and to address key issue - BAD return paths.
>  
>

What other systems? These are all the same systems: systems receiving 
mail via SMTP, sending mail via SMTP and answering CBV connections.

>Look, I am sorry you had a PROBLEM. But you were the exception. Not the norm
>and I am not convince that the CBV protocol I recommend should be abandon or
>ruined for this extremely insignificant issue in todays  real world
>practical operations where it counts and really matters.
>  
>

See my comments above.

>Increasing the timeout to SMTP levels isn't going to work. Period.
>  
>

Right. So CBV is not going to work unless the world changes the way you 
want it to change.

>>And until the time that CBV is documented, it would be good to have some
>>BCP RFC in which it is strongly recommended (BCP 14 "MUST NOT") to not
>>use CBV because it decreases the reliability of the Internet mail system.
>>    
>>
>
>I don't agree with your assessment. And I again, I am sorry you had a
>problem, but as I can see this morning, your RCPT TO response time was
>pretty fast.  So you shouldn't have a problem.
>  
>

I switched to ADSL. Last year I had only IDSN 64kbps. The year before 
last year I had dial-on-demand with a Cisco and I used ETRN to get mail 
from my provider, to keep the cost down. Please keep in mind that not 
every company in this world fits into your model of bandwidth.

>Bottom line, get use to it - the CBV is here to stay, there are numerous
>other systems and maybe I contract all the relevant parties to co-develop a
>draft.   But until a better backward compatible concept is invented to
>validate the sender return path and not just the domain, its here to stay.
>  
>

You may choose whatever you want. As it seems to be a waste of time to 
try to show you that the real world is a bit more complex than you would 
like it to be, this is my last message on this subject.

/rolf

From: "Hector Santos" <[email-masked]>
To: "John C Klensin" <[email-masked]>, "Keith Moore" <[email-masked]>, "Robert A. Rosenberg" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification
Date: Wed, 29 Jun 2005 08:33:33 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

----- Original Message -----
From: "John C Klensin" <[email-masked]>

> And, of course, going to one-recipient-per-message also vastly
> increases total transmission time for messages, especially
> moderately long messages, in normal use.  That total
> transmission time issue -- let's open a minimal number of TCP
> connections and transmit the payload on a target host basis, not
> a target user one-- is, of course, why the multiple RCPT
> provision was included in the mail specs more than a quarter of
> a century ago.

If I read you right, this would be a queue manager design issue.

But I think overall two different lines of thoughs are mesh - bouncing vs
broadcasting.

IOW,  should a broadcaster be allow to use the NULL ("no bounce needed)
return path?

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

From: "Hector Santos" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: CBV in the real world (was Re: Bounce/System Notification Address Verification)
Date: Wed, 29 Jun 2005 08:30:08 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

From: "Rolf E. Sonneveld" <[email-masked]>

> >But I think it is only fair to ask of Rolf, why was there a long delay in
> >the RCPT TO.  It wasn't a bandwidth problem.   The session was pretty
fast
> >up to the point of the RCPT TO state.  So I think it is an honest
question
> >to seek some technical insight into the problem.

> .... Due to
> bandwidth problems the two or three DNS BL checks may have taken more
> time than the 35 seconds you grant them.

You should consider a performance RBL site switcher based on fast/slow
algorytm.  Move the fastest to the top, slowest to the bottom.  Works really
well when one of the sites is down.

> The lessons of this example are two-fold:
>
>    1. CBV significantly contributes to the load of SMTP connections
>       because the CBV itself initiates all sorts of verifications (like
>       SPF, CSV, DNS domain verify, DNS BL's, static IP BL's, CBV itself
>       in a loopback scenario etc.) and as such decreases the reliability
>       of mail delivery.

hmm, a good generalized statement, but CBV runs on its own. You can't
control what others will have.

>    2. To operate in the real world, CBV would at least have to implement
>       the SMTP timeouts as specified in 2821.

Totally disagree with you here.  Again, it is a real-world case situation
only which is the exception, not the rule.  Most systems are design to run
fast.

If this is required, the CBV is no longer valid and this isn't going to
happen based on this timeout issue..  But more importantly, the numbers
clearly do not back this up.

Remember who you are talking about: Bad systems. Not Good systems.  Good
systems work well.  Bad systems do not. Bad systems do not. Good systems
complains, like you did.

Besides, there are other considerations and ideas to solve this problem.

1) Considering the fact you were having bandwidth issues with your RBL
setup, this is a clear corrective manner on your end.  For example,
decreasing your own socket timeouts for your RBL lookups.

2) Using a 1yz continuation code consideration which ALL clients must
support per RFC x821 specification.  See RFC 2821 Section 4.2.1

4.2.1 Reply Code Severities and Theory
    ....

   1yz   Positive Preliminary reply
      The command has been accepted, but the requested action is being
      held in abeyance, pending confirmation of the information in this
      reply.  The SMTP client should send another command specifying
      whether to continue or abort the action.  Note: unextended SMTP
      does not have any commands that allow this type of reply, and so
      does not have continue or abort commands.

and then read this link in the OPES working group where I prove the proof of
concept.

http://www.imc.org/ietf-openproxy/mail-archive/msg03282.html

In the OPES working group where there is a highest consideration for SMTP
usages. A key consideation is the timeout potentials when the OPES processor
start at a particular state point.

Again, I seek 0% failure rate with 100% automated technical compliance
logic. I don't want false positive any more than you do.

> seems to me Bad Current Practice (please note: to get it working you
> adjust the real world towards your CBV system).Talking about transaction
> time: your CBV system has increased the transaction time for my message
> from less than one minute, to several days with a final result of NDN).

And of course, your bandwidth issues is really not your problem.

Sorry, increasing the CBV timeout to SMTP specified levels, isn't going to
happen. I might increase it to a new default value, but ultimately it is a
sysop configuration item.

On a similar note, I am considering bringing up a  recommendation for
2821bis to consider reducing yesterday's legacy timeout values or atleast
revisit a new fine tuning for today higher bandwidths.  But it really isn't
a big deal.

> I see no reason why your SMTP client implementation would stick to the
> 2821 timeouts, while your CBV implementation would not. In both
> situations the transport is the same.

Thats because you are writing the software to interface with other systems
and to address key issue - BAD return paths.

Look, I am sorry you had a PROBLEM. But you were the exception. Not the norm
and I am not convince that the CBV protocol I recommend should be abandon or
ruined for this extremely insignificant issue in todays  real world
practical operations where it counts and really matters.

Increasing the timeout to SMTP levels isn't going to work. Period.

> And until the time that CBV is documented, it would be good to have some
> BCP RFC in which it is strongly recommended (BCP 14 "MUST NOT") to not
> use CBV because it decreases the reliability of the Internet mail system.

I don't agree with your assessment. And I again, I am sorry you had a
problem, but as I can see this morning, your RCPT TO response time was
pretty fast.  So you shouldn't have a problem.

There a better solutions to increasing the timeout as I suggested above.

Bottom line, get use to it - the CBV is here to stay, there are numerous
other systems and maybe I contract all the relevant parties to co-develop a
draft.   But until a better backward compatible concept is invented to
validate the sender return path and not just the domain, its here to stay.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: Bounce/System Notification Address Verification
Date: Wed, 29 Jun 2005 08:09:18 -0400
Cc: "Robert A. Rosenberg" <[email-masked]>
Sender: [email-masked]

On Wed June 29 2005 00:41, Robert A. Rosenberg wrote:

> I will rephrase that to be "Since in 98% of the time there is only 
> one Recipient in a <> message, if the sender has some need/desire to 
> send a multi-recipient <> message, then such sender should create a 
> separate copy for each recipient and thus send them as 
> single-recipient copies".

Where precisely does that "98%" figure come from?  Do you have statistics
on all messages sent through all servers?  Or was the number plucked out
of thin air, with no more validity than any other random number between
0% and 100%?

As Keith has noted, there is no need or value in imposing such a new
requirement at this late date.

> Thus puts the burden of respecting the  
> one-recipient-per-<>-message "rule" where it belongs - on those 
> processes that generate those 2% of the <> Messages by requiring them 
> to make the effort to conform (ie: By sending multiple 
> single-recipient copies).

You have already admitted that there is no such rule.  And I remind you
that an earlier statement of yours began with "OTOH: There is no
requirement that"; sauce for the goose is sauce for the gander.  We are
all agreed that there is no requirement that a message with a null
return path be limited to a single recipient.

Date: Wed, 29 Jun 2005 08:06:38 -0400
From: Keith Moore <[email-masked]>
To: [email-masked]
Cc: Frank Ellermann <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification
Sender: [email-masked]

>>>we need email to work a lot more often than 50% of the time.
>>>really, one failure in ten thousand legitimate messages is
>>>too high...we should be able to achieve one failure in a
>>>hundred thousand messages or better.
>>
>>Is that the principle why the IESG approved a mail experiment
>>where each and every mail with MAIL FROM != 2822-From without
>>2822-Sender fails, if the MAIL FROM has a v=spf1 FAIL-policy ?
> 
> 
> No, that would be the principle that an experiment only affects
> those who choose to participate in the experiment, and if the
> experiment is a failure, no great harm is done to the deployed
> infrastructure at large.

which of course is not true in this case.

Frank, if you were willing to write up an I-D of the form "SPF 
experiment considered harmful", explaining just why this is a Bad Idea, 
that might be a valuable community service.

Keith

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: Bounce/System Notification Address Verification
Date: Wed, 29 Jun 2005 08:02:54 -0400
Cc: "Robert A. Rosenberg" <[email-masked]>
Sender: [email-masked]

On Wed June 29 2005 00:30, Robert A. Rosenberg wrote:
> 
> At 13:50 +0100 on 06/28/2005, Tony Finch wrote about Re: 
> Bounce/System Notification Address Verification:

> >However if the return path might have been an alias which expands to more
> >than one address, and this can reslult in legitimate bounces with more
> >than one recipient.

> No it doesn't. The original message has ONE recipient (the alias) and 
> gets delivered to it. At that point the alias gets expanded and 
> creates a new message which is sent to each recipient. Unless 2 or 
> more recipients are hosted at some domain other than the one where 
> the alias is hosted, each copy is delivered directly to their mailbox 
> (as if the message had arrived with all the addresses explicitly 
> listed as RCPT-TOs).

You might want to reread Tony's statement carefully.  Perhaps an
example will help:

Original message:
Return-Path: [email-masked]
...

Bounce:
Return-Path: <>
To: [email-masked]
...

which may well be expanded to multiple RCPT TO mailboxes.

Date: Wed, 29 Jun 2005 07:59:51 -0400
From: Keith Moore <[email-masked]>
To: Frank Ellermann <[email-masked]>
Cc: [email-masked]
Subject: Re: Bounce/System Notification Address Verification
Sender: [email-masked]

>>we need email to work a lot more often than 50% of the time.
>>really, one failure in ten thousand legitimate messages is
>>too high...we should be able to achieve one failure in a
>>hundred thousand messages or better.
> 
> 
> Is that the principle why the IESG approved a mail experiment
> where each and every mail with MAIL FROM != 2822-From without
> 2822-Sender fails, if the MAIL FROM has a v=spf1 FAIL-policy ?

you'll have to ask IESG.  I'm not responsible for their decisions, and I 
certainly don't agree with all of them.

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: Bounce/System Notification Address Verification
Date: Wed, 29 Jun 2005 07:55:37 -0400
Cc: Frank Ellermann <[email-masked]>, [email-masked]
Sender: [email-masked]

On Wed June 29 2005 02:05, Frank Ellermann wrote:
> 
> Keith Moore wrote:
> 
> > we need email to work a lot more often than 50% of the time.
> > really, one failure in ten thousand legitimate messages is
> > too high...we should be able to achieve one failure in a
> > hundred thousand messages or better.
> 
> Is that the principle why the IESG approved a mail experiment
> where each and every mail with MAIL FROM != 2822-From without
> 2822-Sender fails, if the MAIL FROM has a v=spf1 FAIL-policy ?

No, that would be the principle that an experiment only affects
those who choose to participate in the experiment, and if the
experiment is a failure, no great harm is done to the deployed
infrastructure at large.

From: "Hector Santos" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, "Russ Allbery" <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification
Date: Wed, 29 Jun 2005 07:51:47 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

From: "Rolf E. Sonneveld" <[email-masked]>

> You are creating an artificial difference between 'real world' and
> 'practical world'.

I did no such thing.

> >    From: "Rolf E. Sonneveld"
> >
> >    "I suspect the timeout values you use (or used) for your CBV are set
too
> >    small to be useable in the real world of the Internet."
>
> Please don't change my words. I said what I said, period.

You sure did!  But I didn't change your words,  Russ did. I just cited an
example of what you didn't say.   I read it exactly how you meant it.

> >This would imply that 49% of all CBV sessions will fail due to a timeout.

> What I read in Keiths words is that standards should work for 99.999
> percent of all cases and we should not be satisified with success for
> anywhere between 50 percent and 99.999 percent. If a new SMTP model with
> built-in anti-spam protection will be designed, it would need to aim at
> least to this kind of reliability (> 99.999 percent).

So in the practical world, you mean 100%?

and why 1 in 100,000?  Is that good enough for you?

1 in 100,000 is way too high of a failure rate in my book and I wouldn't
presume a new SMTP model to begin with a broken concept regardless of how
small it may be in the final analysis.

Anyway, you were the 1 in 1.1 million for our system.  Now that is what I
call negligible.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

Date: Wed, 29 Jun 2005 07:54:06 -0400
From: John C Klensin <[email-masked]>
To: Keith Moore <[email-masked]>, "Robert A. Rosenberg" <[email-masked]>
cc: [email-masked]
Subject: Re: Bounce/System Notification Address Verification
Sender: [email-masked]

--On Wednesday, 29 June, 2005 00:50 -0400 Keith Moore
<[email-masked]> wrote:

>> I am not rejecting anything. All I am suggesting is that when
>> more than  one recipient is to be used for the message, to
>> generate a separate copy  for each recipient (with only that
>> recipient listed as the "To") so  there are separate copies
>> (as would occur with multi-recipient [messages  where each
>> recipient is in a different domain] at the MTA stage ).
> 
> Why should an MTA or MUA bother to do this?  This part of the
> SMTP standard has been stable since c. 1980 and it has _never_
> required this.
>...
> spammers have consistently shown themselves to be very
> flexible at adapting to far more substantial countermeasures.
> and it's much easier for spammers to adapt than for the vast
> installed base to adapt.  it is counterproductive to impose
> meaningless restrictions on legitimate senders.  in the long
> term this only adds complexity and damages transparency of the
> mail system without doing anything to discourage spam.

And, of course, going to one-recipient-per-message also vastly
increases total transmission time for messages, especially
moderately long messages, in normal use.  That total
transmission time issue -- let's open a minimal number of TCP
connections and transmit the payload on a target host basis, not
a target user one-- is, of course, why the multiple RCPT
provision was included in the mail specs more than a quarter of
a century ago.

Folks, I don't know how to say this more strongly, but, if we
are willing to wreck the normal and efficient functioning of the
mail system in order to reduce the amount of spam that gets
delivered, there are, well, more efficient ways to wreck the
mail system.

    john

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: Bounce/System Notification Address Verification
Date: Wed, 29 Jun 2005 07:53:15 -0400
Cc: "Robert A. Rosenberg" <[email-masked]>
Sender: [email-masked]

On Wed June 29 2005 01:40, Robert A. Rosenberg wrote:

> There is only (as I've noted in a prior message) a flaw if when 
> [a] CBV probes an ISP and that ISP CBVs back in response to the 
> probe, [the first sysrem] instead of accepting the CBV probe and responding with 
> a "Good Address" reply turns around and tries to CBV the other 
> Server. It is the job of [...] CBV users [...] to recognize 
> the addresses used with their CBV probes and not respond with a CBV 
> probe when the address is used by another CBV system. You handle CBV 
> probles triggered by your own in-flight CBV probes do not require 
> your CBV code to recognize other user's CBV probe patterns (ie: you 
> should just CBV respond to them).

Then it is the responsibility of the (nonexistent?) specification
authors to completely specify such behavior, and as this is clearly
an interoperability issue which if ignored can result in damage to
the mail system is needs to be specified with use of BCP 14 MUST or
MUST NOT.

Date: Wed, 29 Jun 2005 13:05:07 +0200
From: "Rolf E. Sonneveld" <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification
To: Hector Santos <[email-masked]>
Cc: [email-masked], Russ Allbery <[email-masked]>
Reply-to: [email-masked]
Organization: Sonnection B.V.
Sender: [email-masked]

Hector Santos wrote:

[...]

>>Incidentally, one can make a fairly strong argument that the whole point
>>of standards is to get things to work in edge and minority cases.
>>    
>>
>
>Is this the real world?  <g>
>  
>

YES IT IS.

>I agree, and one might suggest this includes RFC 822/821 standard
>considerations, as well as the idiosyncracies one might find in the real
>world hetegeneous blend of legacy and modem implementations.  In the real
>practical world,  you have to maximize your support for compliancy cross the
>board and you can only hope this covers the "majority" as well as the
>minority who do not comply to your set complete of standards.
>  
>

You are creating an artificial difference between 'real world' and 
'practical world'. There is no difference. Standards should aim at 
supporting all situations, not just support the 'majority' and 'hope for 
the best for the minority'.

[...]

>But, in fact, he did not use the term "cases."  If indeed it was stated as
>such, I would agree with you. But that was not what was stated. He did not
>say "cases" which puts a whole new practical spin in it.  Lets recall what
>Rolf stated:
>
>    From: "Rolf E. Sonneveld"
>
>    "I suspect the timeout values you use (or used) for your CBV are set too
>    small to be useable in the real world of the Internet."
>
>This basically implies "its not practical" and when something is not
>practical, it is unusable or useful in the "real world."   If you want to
>inject "cases" into the statement, we might have:
>
>    "I suspect the timeout values you use (or used) for your CBV are set too
>    small to be useable in specific real world cases in the Internet."
>  
>

Please don't change my words. I said what I said, period.

[...]

>Keith says 49% of all systems have a delay of 35 seconds or more at the
>first RCPT TO command.
>  
>

Keith can speak for himself, but this is definitely not what I read in 
his words.

>This would imply that 49% of all CBV sessions will fail due to a timeout.
>  
>

What I read in Keiths words is that standards should work for 99.999 
percent of all cases and we should not be satisified with success for 
anywhere between 50 percent and 99.999 percent. If a new SMTP model with 
built-in anti-spam protection will be designed, it would need to aim at 
least to this kind of reliability (> 99.999 percent).

/rolf

Date: Wed, 29 Jun 2005 13:02:30 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Bounce/System Notification Address Verification
Cc: Hector Santos <[email-masked]>, Valdis =?utf-8?q?Kl=C4=93tnieks?= <[email-masked]>, [email-masked]
Sender: [email-masked]

It should perhaps be noted that one increasingly fashionable antispam 
trick is to use a longish delay before sending the banner or responding 
to a command. A friend of mine reports good results with a 46-second 
delay. He says lots of spammers time out 45 seconds after sending RCTP 
TO.

Arnt

Date: Wed, 29 Jun 2005 12:32:57 +0200
From: "Rolf E. Sonneveld" <[email-masked]>
Subject: CBV in the real world (was Re: Bounce/System Notification Address Verification)
To: Hector Santos <[email-masked]>
Cc: [email-masked], [email-masked]
Reply-to: [email-masked]
Organization: Sonnection B.V.
Sender: [email-masked]

[Renamed the subject line as it seems that there are now three different 
threads carrying the same subject line.]

Hector Santos wrote:

[...]

>Yes, there are considerations. The short timeout is a factor in all this.
>But its only been an exception, such as Rolf, a valid false positive due to
>the shorter timeout.
>
>But I think it is only fair to ask of Rolf, why was there a long delay in
>the RCPT TO.  It wasn't a bandwidth problem.   The session was pretty fast
>up to the point of the RCPT TO state.  So I think it is an honest question
>to seek some technical insight into the problem.
>  
>

My system is doing DNS BL verification at the stage _after_ the RCPT TO 
command, to be able to selectively whitelist specific sender-recipient 
combinations, e.g. for some large ISPs for which outbound MTa's 
occassionally are blacklisted, but from which some mail is required to 
pass the filter (wanadoo.fr is an example that comes to mind). Due to 
bandwidth problems the two or three DNS BL checks may have taken more 
time than the 35 seconds you grant them.

The lessons of this example are two-fold:

   1. CBV significantly contributes to the load of SMTP connections
      because the CBV itself initiates all sorts of verifications (like
      SPF, CSV, DNS domain verify, DNS BL's, static IP BL's, CBV itself
      in a loopback scenario etc.) and as such decreases the reliability
      of mail delivery.
   2. To operate in the real world, CBV would at least have to implement
      the SMTP timeouts as specified in 2821.

To cite from RFC2821:

>   Based on extensive experience with busy mail-relay hosts, the minimum
>   per-command timeout values SHOULD be as follows:
>
>   Initial 220 Message: 5 minutes
>      An SMTP client process needs to distinguish between a failed TCP
>      connection and a delay in receiving the initial 220 greeting
>      message.  Many SMTP servers accept a TCP connection but delay
>      delivery of the 220 message until their system load permits more
>      mail to be processed.
>
>   MAIL Command: 5 minutes
>
>   RCPT Command: 5 minutes
>      A longer timeout is required if processing of mailing lists and
>      aliases is not deferred until after the message was accepted.
>  
>

This means you should start by increasing the overall timeout for your 
CBV system to at least 15 minutes (900 seconds), which is quite 
different from the current 35 seconds. Minimizing these values as you 
state because:

>To reduce the transaction time, short times are used for the CBV.  With few
>exceptions, this has not seem to be a problem.  By far, where there is a
>problem, it is zombie sites.
>

seems to me Bad Current Practice (please note: to get it working you 
adjust the real world towards your CBV system).Talking about transaction 
time: your CBV system has increased the transaction time for my message 
from less than one minute, to several days with a final result of NDN). 
I see no reason why your SMTP client implementation would stick to the 
2821 timeouts, while your CBV implementation would not. In both 
situations the transport is the same.

IMO, standardizing/documenting CBV should be done, but only to 
_minimize_ the harm and impact it already creates.

And until the time that CBV is documented, it would be good to have some 
BCP RFC in which it is strongly recommended (BCP 14 "MUST NOT") to not 
use CBV because it decreases the reliability of the Internet mail system.

/rolf

From: "Hector Santos" <[email-masked]>
To: <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification
Date: Wed, 29 Jun 2005 06:17:30 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

From: "Keith Moore" <[email-masked]>

> nope.  what I'm implying is that the inability to verify a return
> address via SMTP within 35 seconds is a poor criterion for failing to
> deliver a message.  yes, the _majority_ (> 50%) of verifications will
> complete in this time, but we need email to work a lot more often than
> 50% of the time.

Fair statement, but I contest the >50% simply because that will imply at
least 49% of all CBV sessions would fail due to a 35 timeout which is
clearly not the case.

> really, one failure in ten thousand legitimate
> messages is too high...we should be able to achieve one failure in a
> hundred thousand messages or better.

Is this a standard criteria for acceptance?    If so, our statistics meet
this criteria.

Nonetheless, I prefer to seek 0% failure rate at the SMTP level that is
completely independent on the mail content interpretations.

> > The context of the statement is based on the OP assertion that low
timeouts
> > (35 seconds in this case) "will not work in the real world of internet
> > email" which implies the majority of all systems.
>
> it doesn't imply any such thing - that's just your interpretation.  for
> most of us on this list, a system that only works a "majority" of the
> time isn't nearly reliable enough.

If my interpretation is incorrect, then your interpretation and the people
you are speaking for suggest that it must work 95%,  98%, 99% or 100% of the
time?

You just stated above that a 1 in 100,000 failure rate is an acceptable
failure rate.  That isn't 100%.

Which is it? What is "reliable" for keith?

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

From: "Hector Santos" <[email-masked]>
To: <[email-masked]>, "Russ Allbery" <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification
Date: Wed, 29 Jun 2005 05:35:24 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

From: "Russ Allbery" <[email-masked]>

> Using "the real world" synonymously with "a majority" is an extremely
> idiosyncratic usage.  I don't believe I've ever seen that usage before.

hmmm, I don't know what to say. :-)

> Incidentally, one can make a fairly strong argument that the whole point
> of standards is to get things to work in edge and minority cases.

Is this the real world?  <g>

I agree, and one might suggest this includes RFC 822/821 standard
considerations, as well as the idiosyncracies one might find in the real
world hetegeneous blend of legacy and modem implementations.  In the real
practical world,  you have to maximize your support for compliancy cross the
board and you can only hope this covers the "majority" as well as the
minority who do not comply to your set complete of standards.

> If all we ever cared about was working with a majority of sites a majority
of the
> time, a standard often wouldn't be necessary.

True, but standards are often based on the majority usage or implementation.
That is what usually what makes it a standard.   You are 100% compliant with
822/821, but not with 2821/2822.  Are you in the majority or minority?
Theoritically, 2821/2822 are still only proposed standards.  When a phishing
2822 compliant message arrives, will the 821/822 compliant only system
reject it for lack of a destination header (To:)? or will it inject the To:
header based on the 821 RCPT TO forwarding path and accept the message?
How will new servers supporting the new pending standard SenderId/PRA whichl
imposes a 100% strict 2822 header requirment in the DATA work when in fact,
the majority of the current servers  do not require x822 headers in the DATA
block for the message to be accepted?

So Russ. I understand clearly what you are saying, but I hope you can
understand that for any new idea you might have, there will always be issues
of majority vs minority.

For something that is sensitive as the Return Path,  we should expect to be
issues, but how much?

> For what it's worth, I would never have read that meaning into that
> sentence.  I read that sentence as saying that using such a timeout would
> break in real-world cases (as opposed to only violating some theoretical
> and unnecessary principle in a standard).  And, in fact, it did.

But, in fact, he did not use the term "cases."  If indeed it was stated as
such, I would agree with you. But that was not what was stated. He did not
say "cases" which puts a whole new practical spin in it.  Lets recall what
Rolf stated:

    From: "Rolf E. Sonneveld"

    "I suspect the timeout values you use (or used) for your CBV are set too
    small to be useable in the real world of the Internet."

This basically implies "its not practical" and when something is not
practical, it is unusable or useful in the "real world."   If you want to
inject "cases" into the statement, we might have:

    "I suspect the timeout values you use (or used) for your CBV are set too
    small to be useable in specific real world cases in the Internet."

Then we have the different meaning.  One applies to the majority or most
common implementation in the real world, and the other applies to the
minority or subset implementation in the real world.

I only disagree because we have the "practical" experience and statistics to
suggest the original statement is untrue.

I respect the fact you might disagree, but to me, we are moving to debating
semantics about concepts that really doesn't apply.

I am not looking for a "majority" behavior as part of the design. I am
looking for an exact behavior that is based on SMTP compliance.  The reality
is that some where in-between the exact world and the real world, there is
majority and minority behavior.  You can only hope the two are at far
extreme ends opposite of each other.

So we have a CBV,  100% SMTP-based callback client with the exception of a
shorter timeouts that the official SMTP specification  The question is, is
the timeout issue a significant problematic issue, and if so, can it be
addressed. If not, you dump CBV.

Keith says 49% of all systems have a delay of 35 seconds or more at the
first RCPT TO command.

This would imply that 49% of all CBV sessions will fail due to a timeout.

This is way far from reality. For own system alone,  it is closer to
0.000001%  1 in 1.1 million message.

Please note, very important, this is a good system.  There is a greater
amount when it happens on bad/zombies who intentionally break sessions.
These were the ones reported to use by customers.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

Date: Wed, 29 Jun 2005 01:57:04 -0400
To: [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification
Sender: [email-masked]

At 13:24 -0400 on 06/28/2005, [email-masked] wrote about Re: 
Bounce/System Notification Address Verification:

>On Tue, 28 Jun 2005 18:04:02 BST, Tony Finch said:
>>  On Tue, 28 Jun 2005 [email-masked] wrote:
>>  >
>>  > The first rule of any protocol is that it has to interoperate with itself.
>>  > The fact that this design *is* prone to disastrous loops when it 
>>encounters
>>  > other CBV systems with similar design flaws shows that the 
>>concept is flawed.
>>
>>  You haven't demonstrated that Verizon's implementation is flawed 
>>in this way.
>
>OK.. I spell it out in excruciating detail:
>
>Verizon presents me with MAIL FROM:<[email-masked]>
>
>I do a CBV on MAIL FROM, same as Verizon, and send them a connection 
>that starts
>MAIL FROM:<[email-masked]> - they see that mail from, 
>and do what?

Not CBV back I'd hope but just reply that 
[email-masked] is valid and see what happens next 
(which SHOULD be a QUIT in this reverse CBV case).

>
>[snip]
>
>Also, absent a new, as-yet-unRFC'ed SMTP extension, the remote end can't just
>assume that something is a CBV and ignore it - to do so would allow 
>a spammer to send you a MAIL FROM/RCPT TO on a first connection, 
>then once the callback shows up, use *that* information to create 
>what looks like a "callback to a callback", but proceed to the DATA 
>step. Whoops.. ;)

If the response to the "Its Valid" reply is anything other then a 
QUIT (ie: If the sender tries to go into Data State) then just drop 
the connection since the ONLY valid reply to the CBV check is a QUIT.

Date: Wed, 29 Jun 2005 01:40:13 -0400
To: [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification
Sender: [email-masked]

At 18:04 +0100 on 06/28/2005, Tony Finch wrote about Re: 
Bounce/System Notification Address Verification:

>On Tue, 28 Jun 2005 [email-masked] wrote:
>>
>>  The first rule of any protocol is that it has to interoperate with itself.
>>  The fact that this design *is* prone to disastrous loops when it encounters
>>  other CBV systems with similar design flaws shows that the concept 
>>is flawed.
>
>You haven't demonstrated that Verizon's implementation is flawed in this way.

There is only (as I've noted in a prior message) a flaw if when 
Verizon CBV probes an ISP and that ISP CBVs back in response to the 
probe, Verizon instead of accepting the CBV probe and responding with 
a "Good Address" reply turns around and tries to CBV the other 
Server. It is the job of Verizon (and other CBV users) to recognize 
the addresses used with their CBV probes and not respond with a CBV 
probe when the address is used by another CBV system. You handle CBV 
probles triggered by your own in-flight CBV probes do not require 
your CBV code to recognize other user's CBV probe patterns (ie: you 
should just CBV respond to them).

>
>Tony.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Bounce/System Notification Address Verification
Date:  Wed, 29 Jun 2005 08:05:03 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 18
Cc: <[email-masked]>
Sender: [email-masked]

Keith Moore wrote:

> we need email to work a lot more often than 50% of the time.
> really, one failure in ten thousand legitimate messages is
> too high...we should be able to achieve one failure in a
> hundred thousand messages or better.

Is that the principle why the IESG approved a mail experiment
where each and every mail with MAIL FROM != 2822-From without
2822-Sender fails, if the MAIL FROM has a v=spf1 FAIL-policy ?

Intentionally causing harm.

> for most of us on this list, a system that only works a
> "majority" of the time isn't nearly reliable enough.

I'd love to believe you, but unfortunately I can't.  Bye

Date: Wed, 29 Jun 2005 00:46:56 -0400
To: [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification
Sender: [email-masked]

At 10:29 -0400 on 06/28/2005, [email-masked] wrote about Re: 
Bounce/System Notification Address Verification:

>OK, let's throw out support for HELO

It SHOULD be thrown out for Port587 MSA SMTP Servers since it is an 
INVALID Command to send to start a session with such Servers since it 
will not trigger the required 220 reply with the AUTH listing of 
supported methods needed to send the authentication credentials.

Date: Wed, 29 Jun 2005 01:10:11 -0400
To: [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification
Sender: [email-masked]

At 12:41 -0400 on 06/28/2005, [email-masked] wrote about Re: 
Bounce/System Notification Address Verification:

>On Tue, 28 Jun 2005 15:55:27 BST, Tony Finch said:
>>  On Tue, 28 Jun 2005 [email-masked] wrote:
>>  >
>>  > Please note that using the near-universally reviled Verizon method as
>>  > anything other than an example of how *not* to do it:
>>  >
>>  > 19:36:18 C: MAIL FROM:<[email-masked]>
>>  >
>>  > Now explain to me why I shouldn't do a CBV on this?
>>
>>  And if you do, what do you expect to happen? If Verizon calls back in
>>  response to your callback (i.e. they're doing CBV for email to
>  > [email-masked]) then they are asking for a disastrous
>>  callback loop. However this will only occur if your system has the same
>>  bug.
>
>The first rule of any protocol is that it has to interoperate with itself.
>The fact that this design *is* prone to disastrous loops when it encounters
>other CBV systems with similar design flaws shows that the concept is flawed.
>

While I agree with you, I'd like to point out that the only way there 
would be  callback loop is if the originator of the CBV's machine 
does CBV when its address is verified. IOW, when 
[email-masked] is checked it should NOT CBV but just 
return a "Its a Good Address" indication. When ISP1 sends a message 
to ISP2 (which CBVs ISP1), the CBV that ISP1 responds with to IPS2's 
CBV attempt is ISP2's responsibility to handle (ie: To not do a CVB 
on) since ISP2 KNOWS that it probably is an CBV triggered by its CBV. 
A good CVB design should not need to "special case" CBV attempts (by 
having a list of the hosts/address-templates of ISPs that CBV and 
thus should not be CBV'ed back) but should just rely on the 
originator to handle the CBV its own CBV triggered.

Date: Wed, 29 Jun 2005 00:41:48 -0400
To: [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification
Sender: [email-masked]

At 10:17 -0400 on 06/28/2005, [email-masked] wrote about Re: 
Bounce/System Notification Address Verification:

>On Mon, 27 Jun 2005 21:10:38 EDT, Hector Santos said:
>
>>  Keith, we were referring (atleast I was) to the fact that they do EXIST 1
>>  RCPT limits for a NULL return path.  There are plenty of systems that work
>>  in this mode whether you care to believe that or not.  The conflict you seem
>>  to forget is that your multi rcpt-to/null return path allowance is a source
>>  of spam.
>
>No, what *I* said was that since, *in general*, a bounce only has 1 MAIL FROM
>to generate RCPT TO's, and there's a lot of idiot mail admins that feel
>justified in saying "Since this is true 98% of the time, we will force it
>to be true always...."

I will rephrase that to be "Since in 98% of the time there is only 
one Recipient in a <> message, if the sender has some need/desire to 
send a multi-recipient <> message, then such sender should create a 
separate copy for each recipient and thus send them as 
single-recipient copies". Thus puts the burden of respecting the 
one-recipient-per-<>-message "rule" where it belongs - on those 
processes that generate those 2% of the <> Messages by requiring them 
to make the effort to conform (ie: By sending multiple 
single-recipient copies).

Date: Wed, 29 Jun 2005 00:30:15 -0400
To: IETF-SMTP <[email-masked]>
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification
Sender: [email-masked]

At 13:50 +0100 on 06/28/2005, Tony Finch wrote about Re: 
Bounce/System Notification Address Verification:

>On Mon, 27 Jun 2005 [email-masked] wrote:
>
>>  On Mon, 27 Jun 2005 12:38:42 EDT, Hector Santos said:
>>
>>  > What is the BCP for allowing multiple RCPT TO when the return 
>>path is NULL?
>>
>>  In general, since the message that's sent with the null MAIL FROM generates
>>  the RCPT TO from the inbound MAIL FROM, and there's only one of those, then
>>  you can only get one outbound RCPT TO.
>
>However if the return path might have been an alias which expands to more
>than one address, and this can reslult in legitimate bounces with more
>than one recipient.
>
>Tony.

No it doesn't. The original message has ONE recipient (the alias) and 
gets delivered to it. At that point the alias gets expanded and 
creates a new message which is sent to each recipient. Unless 2 or 
more recipients are hosted at some domain other than the one where 
the alias is hosted, each copy is delivered directly to their mailbox 
(as if the message had arrived with all the addresses explicitly 
listed as RCPT-TOs).

To: [email-masked]
Subject: Re: Bounce/System Notification Address Verification
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Tue, 28 Jun 2005 21:56:08 -0700
Sender: [email-masked]

Robert A Rosenberg <[email-masked]> writes:

> OK - Not a Rule but only the usual occurrence with <> messages such as
> "can not deliver" messages. If those functions that generate
> multi-recipient messages with a <> from would just create a separate
> copy for each recipient it would make SPAM detection (of <> messages)
> much easier since any attempt to deliver such a multi-recipient <>
> message would be trappable without needing to bother asking if it was
> possibly a legitimate message or SPAM.

If you set up a digital camera to sound an alarm whenever anyone enters
your house wearing plaid, since no one you know wears plaid, you'll also
be quite effective at detecting any attempts by plaid-wearing burglars to
rob your house.

However, if everyone does this, burglars will just start wearing stripes,
your system will become useless complexity, and several years later after
you've forgotten all about it, you'll end up putting your Uncle Albert in
the hospital with a heart attack due to an unfortunate fashion choice.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Wed, 29 Jun 2005 00:50:18 -0400
From: Keith Moore <[email-masked]>
To: "Robert A. Rosenberg" <[email-masked]>
Cc: [email-masked]
Subject: Re: Bounce/System Notification Address Verification
Sender: [email-masked]

> I am not rejecting anything. All I am suggesting is that when more than 
> one recipient is to be used for the message, to generate a separate copy 
> for each recipient (with only that recipient listed as the "To") so 
> there are separate copies (as would occur with multi-recipient [messages 
> where each recipient is in a different domain] at the MTA stage ).

Why should an MTA or MUA bother to do this?  This part of the SMTP 
standard has been stable since c. 1980 and it has _never_ required this.

> OK - Not a Rule but only the usual occurrence with <> messages such as 
> "can not deliver" messages. If those functions that generate 
> multi-recipient messages with a <> from would just create a separate 
> copy for each recipient it would make SPAM detection (of <> messages) 
> much easier 

no it wouldn't.  it would just mean that spammers would have to use 
another return address besides <> or send only one RCPT per session. 
it's not as if the check you propose imposes much of a hurdle for 
spammers to clear.

spammers have consistently shown themselves to be very flexible at 
adapting to far more substantial countermeasures.   and it's much easier 
for spammers to adapt than for the vast installed base to adapt.  it is 
counterproductive to impose meaningless restrictions on legitimate 
senders.  in the long term this only adds complexity and damages 
transparency of the mail system without doing anything to discourage spam.

Keith

To: [email-masked]
Subject: Re: Bounce/System Notification Address Verification
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Tue, 28 Jun 2005 21:49:30 -0700
Sender: [email-masked]

Hector Santos <[email-masked]> writes:

> Just consider what you are believe.  If this was the case, then you
> would be implying that the majority of all world wide transacitons take
> 35 or more seconds just to complete the first RCPT TO command providing
> you a minimum of 35+ total transaction time (not including the payload
> transfer time and any possible MFA delays).

Using "the real world" synonymously with "a majority" is an extremely
idiosyncratic usage.  I don't believe I've ever seen that usage before.
Given that, I don't think you should find it particularly suprising that
people don't understand what you're talking about when you use the term
with that definition and don't define it first.

Incidentally, one can make a fairly strong argument that the whole point
of standards is to get things to work in edge and minority cases.  If all
we ever cared about was working with a majority of sites a majority of the
time, a standard often wouldn't be necessary.

> The context of the statement is based on the OP assertion that low
> timeouts (35 seconds in this case) "will not work in the real world of
> internet email" which implies the majority of all systems.

For what it's worth, I would never have read that meaning into that
sentence.  I read that sentence as saying that using such a timeout would
break in real-world cases (as opposed to only violating some theoretical
and unnecessary principle in a standard).  And, in fact, it did.

Whether you care or not is another question.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Wed, 29 Jun 2005 00:42:30 -0400
From: Keith Moore <[email-masked]>
To: Hector Santos <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Bounce/System Notification Address Verification
Sender: [email-masked]

>>>The real world DOES NOT have delay RCPT TO value of 35
>>>seconds or more.   That is a fact.
> 
>>Yeah, whatever.  If you choose to believe in a world that contradicts
>>your own observations, don't expect anyone else to go along with it.
> 
> Just consider what you are believe.  If this was the case, then you would be
> implying that the majority of all world wide transacitons take 35 or more
> seconds just to complete the first RCPT TO command providing you a minimum
> of 35+ total transaction time (not including the payload transfer time and
> any possible MFA delays).

nope.  what I'm implying is that the inability to verify a return 
address via SMTP within 35 seconds is a poor criterion for failing to 
deliver a message.  yes, the _majority_ (> 50%) of verifications will 
complete in this time, but we need email to work a lot more often than 
50% of the time.  really, one failure in ten thousand legitimate 
messages is too high...we should be able to achieve one failure in a 
hundred thousand messages or better.

> The context of the statement is based on the OP assertion that low timeouts
> (35 seconds in this case) "will not work in the real world of internet
> email" which implies the majority of all systems.

it doesn't imply any such thing - that's just your interpretation.  for 
most of us on this list, a system that only works a "majority" of the 
time isn't nearly reliable enough.

Keith

Date: Wed, 29 Jun 2005 00:20:32 -0400
To: [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification
Sender: [email-masked]

At 08:24 -0400 on 06/28/2005, Bruce Lilly wrote about Re: 
Bounce/System Notification Address Verification:

>On Tue June 28 2005 01:42, Robert A. Rosenberg wrote:
>>
>>  At 16:34 -0400 on 06/27/2005, Keith Moore wrote about Re:
>>  Bounce/System Notification Address Verification:
>>
>>  >Wrong.  There is no prohibition that I'm aware of against using <> for
>>  >other purposes, and there are some standards that specifically require
>>  >using <> - e.g. MDNs and responses from mail robots, neither of
>>  >which are constrained to exactly one recipient.
>>
>>  OTOH: There is no requirement that the generator of these responses
>>  (when presented with a request/need to sent such a message to more
>>  than one recipient) create a single copy of the message as opposed to
>>  one personally addressed copy per recipient.
>
>You are correct that there is no *requirement*, but sending an MDN to
>multiple recipients is explicitly permitted and in fact may be specified
>by the sender; RFC 3798:
>
>    mdn-request-header = "Disposition-Notification-To" ":"
>              mailbox *("," mailbox)
>
>N.B. multiple MDN recipients may be specified.
>
>Rejecting what is explicitly permitted is probably not a good idea unless
>there is some ancillary information or some overriding consideration.

I am not rejecting anything. All I am suggesting is that when more 
than one recipient is to be used for the message, to generate a 
separate copy for each recipient (with only that recipient listed as 
the "To") so there are separate copies (as would occur with 
multi-recipient [messages where each recipient is in a different 
domain] at the MTA stage ).

>
>Administratively rejecting specific permitted, useful, non-harmful
>information that users have explicitly requested is probably not sound
>policy.
>
>>  Creating multiple copies 
>>  preserves the "Only One Recipient for a 'Mail From <>' message" rule.
>
>Where exactly is that "rule" specified?

OK - Not a Rule but only the usual occurrence with <> messages such 
as "can not deliver" messages. If those functions that generate 
multi-recipient messages with a <> from would just create a separate 
copy for each recipient it would make SPAM detection (of <> messages) 
much easier since any attempt to deliver such a multi-recipient <> 
message would be trappable without needing to bother asking if it was 
possibly a legitimate message or SPAM.

From: "Hector Santos" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification
Date: Wed, 29 Jun 2005 00:10:04 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

From: "Keith Moore" <[email-masked]>

>> The real world DOES NOT have delay RCPT TO value of 35
>> seconds or more.   That is a fact.

> Yeah, whatever.  If you choose to believe in a world that contradicts
> your own observations, don't expect anyone else to go along with it.

Just consider what you are believe.  If this was the case, then you would be
implying that the majority of all world wide transacitons take 35 or more
seconds just to complete the first RCPT TO command providing you a minimum
of 35+ total transaction time (not including the payload transfer time and
any possible MFA delays).

The context of the statement is based on the OP assertion that low timeouts
(35 seconds in this case) "will not work in the real world of internet
email" which implies the majority of all systems.

I disagree with this assertion in that the real world (the majority) do not
operate with lengthy prolonged RCPT TO validations.

A top reason is scalability and large systems performing dynamic validation
will be very inefficient with 35 seconds or more delays.

That does not say it does not exist.  But it is the exception, not the norm.

You might suggest, how about anti-harvesting delays?

Well, if implemented it is usually applied beginning or after a second RCPT
TO, not the first one.

I will venture to believe the real world will agree more than disagree. You
have the right to disagree of course.  I don't think you are being honest
with yourself, and letting other moody issues cloud your comments, but
that's ok.

Thanks for your comment.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

Date: Tue, 28 Jun 2005 21:07:34 -0700
From: Claus Assmann <[email-masked]>
To: Hector Santos <[email-masked]>
Cc: [email-masked]
Subject: Re: Bounce/System Notification Address Verification
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Tue, Jun 28, 2005, Hector Santos wrote:

> 20040311 14:35:45 C: MAIL FROM: <>
> 20040311 14:35:46 S: 250 2.5.0 Address Ok.
> 20040311 14:35:46 C: RCPT TO: <[email-masked]>

Why does your system send a space after the colon?

Let's see whether your CBV still does that.

From: "Hector Santos" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification 
Date: Tue, 28 Jun 2005 23:46:44 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

From: <[email-masked]>

On Tue, 28 Jun 2005 20:20:50 EDT, Hector Santos said:

>> If it was a problem - guaranteed, it would of been DUMP along ago.
>> The real world don't have long delays at RCPT TO.

> So are you saying that Rolf's machine isn't a real part of
> the Internet, or that your Real World excludes problematic
> cases like Rolf's machine?

> I'm trying to understand, so that when you say "real world", I
> know which pieces of the production network you're excluding....

We are all part of the real world.

But I believe when someone states:

        "does not work in the real world"

the suggestion is such the "real world" (a presumption of a majority)
behaves in the same way.

So in my view,  if it is to be stated as such, I disagree and will assert
that the real world (a presumption of a majority) do not behave with
lengthy, prolonged, unresponsive RCPT TO commands.

As I mentioned in the quote,  if indeed this was a problem. the real world
or majority behaved in this manner,  this would be enough of a reason for me
to drop/dump CBV.

I don't think there I have been inconsistent Valdis.

Now, lets go further (because I know you will <g>)

Lets suppose the real world (majority, good and bad)) suddenly began to
intentional delay RCPT TO (for whatever reason, probably as anti-harvesting
concept) as a recommended standard, then I would have to revisit CBV.

The point is, the CBV is only considered because it does fit the BCP.  If it
did not, then I would have to seriously need to dump it.

But lets not make it so severe, so that only the "bad real world" began to
delay RCPT TO, well,  then there would be a justification for rejection.
Because they are bad.

So the next question, why are they bad or rather what makes them bad?

Good question Valdis! :-)

Well, history, statistics.  Over 60-80% (and this is the low ball industry
empirical statistic) says that these are bad transactions.  Our rate shows
94%.  Microsoft says 90%. That outfit says 85%,  another outfit says 75.24%,
etc.

That is only thing you have to go on, that, plus a reliance on conformance
and good operations to even consider CBV.  The payoff is high.

Yes, there are considerations. The short timeout is a factor in all this.
But its only been an exception, such as Rolf, a valid false positive due to
the shorter timeout.

But I think it is only fair to ask of Rolf, why was there a long delay in
the RCPT TO.  It wasn't a bandwidth problem.   The session was pretty fast
up to the point of the RCPT TO state.  So I think it is an honest question
to seek some technical insight into the problem.

I would like to complete this line of questioning (thread) by summarizing
all the technical issues with CBV.

Remember the two basic premises:

    - Compliant expectation for the return path
    - Over 60-80% of transactions are bad.

1) Delaying or the CBV.

For a site with a high volume, and open ended check on the MAIL FROM should
be delayed until the RCPT TO is determined.  This is due to the fact that a
majority of the transactions are bad, hence an high overhead in DNS and
SMTP-based callback will be realized.   A system that does not delay the
CBV, should expect a higher session residence than normal.

2) Short Timeouts

To reduce the transaction time, short times are used for the CBV.  With few
exceptions, this has not seem to be a problem.  By far, where there is a
problem, it is zombie sites.

3) Temporary vs. Permanent Response codes.

Care should be taken to make sure where a proper temporary or permanent
negative response codes should be used for the following.  Default values in
parenthesis were fine tune over time:

- NXDOMAIN (452)
- MX/DNS resolver problem (452)
- No MX records (552)
- Host connections (452)
- Welcome State (452)
- Helo (552)
- Mail From (552)
- Rcpt To (552)

I am open to discussion on the values.

4) CBV session: Defining Client Domain name

Care should be taken to make sure the EHLO/HELO domain matches the machine
of the call back machine.  And it should be a FQDN.  Some systems might be
doing client domain/IP checking.

5) CBV Session: Defining MAIL FROM:

The number #1 concern with a CBV is its high footprint TCP overhead and the
potential for a loopback.   A NULL return path should be used to stop a
short circuit a loopback for maximum capability.

Some implementations have been found to use the postmaster address or some
other proprietary MAIL FROM return path.  Using these could cause a loopback
in two dissimilar CBV systems.   If one is using NULL, the loopback is
atleast 2 deep (1 in both directions).

The reasons for using a non-null return paths has not fully been worked out.
For example, verizon.net MailPass will perform a NULL check and a NON-NULL
check for a rejected RCPT TO address.

6) CBV Session:  Using RCPT TO

Some implementations test only the 1 RCPT TO (Original Sender address).  Our
CBV will test for an open relay if the RCPT TO is accepted using a second
random RCPT TO address.  A false positive can be exhibited if the remote is
operating in post smtp RCPT TO validation.

However, such a system is prune to be a problem in the internet and will
usually be blacklisted by major RBL sites if the host accepts non local
domains addresses (random address).

I can't think of anything else at the moment.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

Date: Tue, 28 Jun 2005 23:00:53 -0400
From: Keith Moore <[email-masked]>
To: Hector Santos <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Bounce/System Notification Address Verification
Sender: [email-masked]

> The real world DOES NOT have delay RCPT TO value of 35 seconds or more.   That is a fact. 

Yeah, whatever.  If you choose to believe in a world that contradicts 
your own observations, don't expect anyone else to go along with it.

Keith

To: Hector Santos <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Bounce/System Notification Address Verification 
From: [email-masked]
Date: Tue, 28 Jun 2005 21:41:54 -0400
Sender: [email-masked]

--==_Exmh_1120009313_9271P
Content-Type: text/plain; charset=us-ascii

On Tue, 28 Jun 2005 20:20:50 EDT, Hector Santos said:

>  I can increase the timeout, but you must understand, it will to address the
> exception rather than the rule.  The real world DOES NOT have delay RCPT TO
> value of 35 seconds or more.   That is a fact.  I can 100% understand that
> it is concern and consideration, but to state the "Real world of the
> intenet" I don't agree with.  Thats like sayiing all the installations are
> just boozo systems leaving in non-real world environments when on the
> countrary, hardly any our mail business customers are hobbiest but small to
> large ISP and businesses world wide.   If it was a problem - guaranteed, it
> would of been DUMP along ago.   The real world don't have long delays at
> RCPT TO.

So are you saying that Rolf's machine isn't a real part of the Internet, or
that your Real World excludes problematic cases like Rolf's machine?

I'm trying to understand, so that when you say "real world", I know which pieces
of the production network you're excluding....

--==_Exmh_1120009313_9271P
Content-Type: application/pgp-signature

--==_Exmh_1120009313_9271P--

From: "Hector Santos" <[email-masked]>
To: "Keith Moore" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification
Date: Tue, 28 Jun 2005 20:41:37 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

Once again,  you can disagree, comment, challenge or whatever, just don't
turn it into a personal attack.

I should also note I have a right to disagree with your subjective opinions
as well, and again, don't use this as a reason to personally attack me.

I acknowledge your expertise of some RFC specifications, but don't use as a
reason to attack me.

You should also acknowledge or atleast at the very least give me some
passive respect for my own expertise,  I don't ask for it, but only out of
common curtsey simply by not personally not attacking me.

If I make a mistake, point it out.  but don't use it as a reason to attack
me.

If I say something that is not consistent with the standard,  point it out,
but don't use this as a reason to attack me.

If I describe something you don't seem to agree with, tell me why, question
it all you want, but don't use this as  reason to attack me.

If you want to keep a personal "hector" folder to keep a watch on my
statements with the intent to challenge me,  sounds pretty sick to me,  but
fine, use it for all the above, just don't use it to personally attack me.

If you have a problem with my ego, well, live with it, just don't use it to
personally attack me.

Can I spell it out any easier?  Can you live with that?  Because if you
don't you we will continue to have a problem.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

----- Original Message -----
From: "Hector Santos" <[email-masked]>
To: "Keith Moore" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, June 28, 2005 4:55 PM
Subject: Re: Bounce/System Notification Address Verification

>
> ----- Original Message -----
> From: "Keith Moore" <[email-masked]>
>
> > > Keith is filtered in a black list - an administrative level policy.
> Instant
> > > notification conforms with US ECPA provisions.
> >
> > Here's the message I'm getting from your server:
> >
> > <[email-masked]>: host mail.winserver.com[208.247.131.9] said: d
In
> ???
> >     550 Return Path not verifiable. (in reply to RCPT TO command)
>
> As it was pointed out on numerous occasions, you are black listed on our
> systems.  We dont' feed trolls reasons to learn how to get around it.
>
> > Personally I don't bounce mail from you - instead I file it into an
> > appropriately-named folder in case I realize that there's a need to read
> or
> > respond to something you've said.
>
> Thanks for the admission. It shows malicious intent to create harm and
> create chaos whenever it suits you.   This has been your undenialable
modus
> operandi towards me for over 2 years now.  There is indisputable proof
that
> that once you begin your attack,  the thread and mail conversations goes
> down the drain.  It has happen with every thread I've participated or
> started with unwarranted attacks at me or my products.   ENUF!  GROW UP
> ALREADY!
>
> > > Nothing you will be able to prove that we are RFC x822 or RFC x821
> > > non-compliant. NOTHING and claiming without proof will cause us
business
> > > harm.
>
> > Everyone in this business gets to succeed or fail based on his
reputation.
>
> Damn right and we have a EXCELLENT reputation in the commercial Online
> Hosting Mail and File distribution, top of the line, and have been for
over
> 25+ years.  A reputation based on ethics and moral values and doing the
> right thing for my customers.  A reputation I cherish and will not allow
to
> be demeaned and defamed.  We are #1 in the online hosting market from
> hobbiest, small, corporate to government, and you don't get there with
> dubious software and system engineering and designs, poor support
> consideraiton, poor quality, non-compliant software as you have stated on
> numerous occassions over the last two years.
>
> > You and your company are no more immune from criticism than anyone
>
> You are correct 100%. Criticism is one things. Lies are not.  Your
criticism
> that attacks our integrity must be based on undisputable *facts*.  You
have
> outrighted demeaned me personally, my company, my products, my customers
on
> numerous occassions over the last 2+ years with statements of unproven
fact
> for one purpose only.  To harm me.  This includes encouraging others to do
> the same with censorship.
>
> Even then I have tried publically and privately ask you on many repeated
> attempts to stop the personal attacks.  I've tried to befriend you but you
> kept the personal attacks going.
>
> You can disagree, tell me I am wrong, dispute whatever I say, hopefully
> showing good reasons, comment or whatever suits you in the course of
public
> mail conversations.  I have thick skin.
>
> But I am going to ask you one final time: DO NOT DEFAME AND TORT MY
PERSON,
> MY COMPANY IN PUBLIC AGAIN.  PLEASE REFRAIN FROM PERSONAL ATTACKS.
>
> --
> Hector Santos, Santronics Software, Inc.
> http://www.santronics.com
>

From: "Hector Santos" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification
Date: Tue, 28 Jun 2005 20:20:50 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

----- Original Message -----
From: "Rolf E. Sonneveld" <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification

>> BUT with 100% without of doubt, no SMTP level false positives that did
not
>> have a meaningful reason.
>
> Excuse me. On March 11, 2004 your server rejected a message of me with
> perfectly legal envelope from address. Part of the message header:

Fair enough. Lets study it.  First, lets ask if you report it?  If so,
please accept my apology.  I don't recall, but if you did, rest assured, it
would of been addressed.  Why would it not be address?

>> Date: Thu, 11 Mar 2004 19:48:02 +0100
>>  From: "Rolf E. Sonneveld" <[email-masked]>

Let me get the log...... last year :-)   ahhhhhh, here we go...

Two attempts tried at 13:47:49 EST and 14:35:37 EST, same results.

Lets use the last one:

Client IP: 193.67.246.66 (unknown)
14:35:37 S: 220 winserver.com Wildcat! ESMTP Server v5.7.450.9b13 ready
14:35:37 C: EHLO donald.sonnection.nl
14:35:37 S: 250-winserver.com, Pleased to meet you.
14:35:37 S: 250-SIZE 5120000
14:35:37 S: 250-ETRN
14:35:37 S: 250-AUTH CRAM-MD5 LOGIN PLAIN PLAIN-MD5 SHA-1
14:35:37 S: 250-AUTH=LOGIN
14:35:37 S: 250 HELP
14:35:39 C: MAIL FROM:<[email-masked]> SIZE=2560
14:35:39 S: 250 <[email-masked]>... Sender validation pending.
Continue.
14:35:39 C: RCPT TO:<[email-masked]>
14:36:45 ** WCX Process: wcsap  ret: 552 (Rejected by WCSAP CBV)
14:36:45 S: 552 Return Path not verifiable.
14:36:46 C: QUIT
14:36:46 S: 221 closing connection

As you can see, there was 1:14 seconds WCX process.  Lets see what
happen at the WCX process:

20040311 14:35:39 -------------------------------------
20040311 14:35:39 version    : 1.55 / 1.54
20040311 14:35:39 calltype   : SMTP
20040311 14:35:39 state      : rcpt
20040311 14:35:39 cip        : 193.67.246.66
20040311 14:35:39 cdn        : donald.sonnection.nl
20040311 14:35:39 from       : <[email-masked]>
20040311 14:35:39 rcpt       : <[email-masked]>
20040311 14:35:39 sapfilter  : pass (time:31)
20040311 14:35:39 saprbl     : testing 66.246.67.193.sbl.spamhaus.org
20040311 14:35:40 saprbl     : testing 66.246.67.193.list.dsbl.org
20040311 14:35:42 saprbl     : testing 66.246.67.193.bl.spamcop.net
20040311 14:35:43 saprbl     : pass
20040311 14:35:44 sapspf     : none (time:1062)
20040311 14:35:44 sapcbv     : total mx records: 3
20040311 14:35:44 try mx     : mail.sonnection.nl ip: 193.67.246.66
20040311 14:35:44 # connecting to 193.67.246.66
20040311 14:35:45 S: 220 donald.sonnection.nl --
                                        Server ESMTP (PMDF V6.2-X10#39908)
20040311 14:35:45 C: NOOP WCSAP v1.55 Wildcat! Sender
                                        Authentication Protocol
http://www.santronics.com
20040311 14:35:45 S: 250 2.0.0 OK.
20040311 14:35:45 C: HELO mail.winserver.com
20040311 14:35:45 S: 250 donald.sonnection.nl OK, [208.247.131.9].
20040311 14:35:45 C: MAIL FROM: <>
20040311 14:35:46 S: 250 2.5.0 Address Ok.
20040311 14:35:46 C: RCPT TO: <[email-masked]>
20040311 14:36:21 C: QUIT
20040311 14:36:45 sapcbv     : -1
20040311 14:36:45 result     : reject (0)
20040311 14:36:45 smtp code  : 552
20040311 14:36:45 reason     : Rejected by WCSAP CBV
20040311 14:36:45 wcsap finish (66125 msecs)

Ok, at 44 seconds, it became the CBV, as you can see thre wasn't a response
to the RCPT TO:   The timeout appears to be  35 seconds.

This is version 1.54, over a year old. The default timeout is 35.  That has
not changed, but I believe we got 2-3 reports among all thousands customers
processing millions of messages, and I recall in each case, it was zombie
sites, so the short delays helped here but I remember the sysops did say
they would increase.

I believe I stated a few times the CBV is a compliant SMTP-based client with
the exception of the timeouts.

> If I remember correctly your CBV rejection had to do with limited
> bandwidth on my side (yes, I live in Europe and bandwidth in Europe may
> still be an issue for small companies). Your CBV system failed to verify
> my mail address (the same address as this very message has), but on that
> same day I received 179 messages in my mailbox, associated with that
> same mail address. Furthermore my server tried to send the message for
> several days, but finally gave up. So the CBV for this message must have
> encountered the same problem for several days, in which I was able to
> receive hundreds of messages from the Internet.

Apparently there is a major delay at RCPT TO.  However, I don't see it as a
bandwidth issue, but rather at your RCPT TO step.  May I ask why it is taken
so long here?  Is this some sort of ant-haverst throttle?

But I am not convince with your statement makes the CBV a flawed concept.

> I suspect the timeout values you use (or used) for your CBV are set too
> small to be useable in the real world of the Internet.

 I can increase the timeout, but you must understand, it will to address the
exception rather than the rule.  The real world DOES NOT have delay RCPT TO
value of 35 seconds or more.   That is a fact.  I can 100% understand that
it is concern and consideration, but to state the "Real world of the
intenet" I don't agree with.  Thats like sayiing all the installations are
just boozo systems leaving in non-real world environments when on the
countrary, hardly any our mail business customers are hobbiest but small to
large ISP and businesses world wide.   If it was a problem - guaranteed, it
would of been DUMP along ago.   The real world don't have long delays at
RCPT TO.

> I reported this  false positive to you, but you blamed my system for
> being unresponsive.

Ok, I don't remember the conversation. But I trust you are correct and if
that is what I said back then, then I can see what happen.  Yes, looking at
the details, it was not a bandwidth issue between your system and ours, but
some unexplainable delay at RCPT TO.

> What are the timeout values for your CBV connections, i.e. primary
> connection setup timeout, timeout for EHLO/HELO, timeout for MAIL FROM
> and timeout for RCPT TO?

As I indicated, 35 seconds is the default.  If anything, it is the only
non-compliant back of the CBV.  I can increase and I doubt it will solve
your problem.

The question you should ask is why the RCPT TO: was taking so long? It
wasn't the bandwidth.

> This brings me back to the topic for which this mailing list does exist:
> SMTP. If CBV is one of the possibile ways to fight spam, the use of it
> should have been documented in some RFC to prevent all sorts of
> interoperability problems.

In the general sense, "Fight Spam" can be used. But from my perspective it
is to validate the Return Path with no consideration to mail content
analysis.   The benefit of such is to fight spam simple because the majority
of the abusers do have bad return paths.

> Such a document on CBV should contain things
> like:
>
>     * timeout values for the various CBV commands

Right.  Making it per state should be a consideration, but keep in mind,
it would be a fine tuning issue because we need to learn about the
exceptions to the rules such as your long or unresponsive RCPT TO command.

>     * mail addresses for which a CBV should not be done (only <>, not
>       postmaster@domain, not mailer-daemon@domain etc., or?)

Right. For backward compatiblity, NULL only should be used.

However, we have been in R&D with with CBV system that understand
each other. I  can't expand on this yet.

>     * how to treat domains names (just use MX technology?) to find out
>       against which host to verify
>     * what to do if there is no MX record, but there is an A record
>       (operate the same way as 2821?)

For backward compatibility, it must support full SMTP client MX lookup.

Please keep in mind of the target audience - the BAD people.

>     * what to do if an MX points to 127.0.0.1

Reject!  If your MTA is calling, that is natural IP based authorized session
on must systems.

>     * what to do if the envelope from address points to one of your own
>       servers (for small enterprises you can reject such messages, but
>       for large scale environments you can't do that, think e.g. of
>       mailing list messages which come back from the Internet with your
>       domain)

A CBV works well when YOU completely established a anonymous final
destination tractions.   Considerations such as your own domains need to be
done before the CBV,  but you also need to make sure your own domains are
not spoofed by unknown IPs.

Lets check if you have an SPF record.... No.  You should consider adding
SPF support, this will help you protect 100% your local domains.

>     * how to deal with situations where primary MX host is down,
>       secondary is up, secondary does not know which address is valid
>       and which is, outbound MTA suffers from CBV because primary MX is
>       down)

Again, a full SMTP client MX expansion logic (Thanks to Valdis to help me
get the most of all the consideraitons here.)  For a CBV,  the only thing
you can only do is issue a temporary negative response code (45x).

Fortunately, again, if it wasn't for the fact that over 60-80% of the
transactions are bad, then the CBV would not have a big payoff.

The good systems will try again, the bad systems will not.  Maybe they will
with a different transaction, but they ususally do not.  You see it, but
what really funny is to seem some that try different RCPT TO: but with the
same return paths. :-)

> So let me suggest you write this document and then send it to ietf-smtp
> for review (I think ietf-smtp is appropriate, as CBV seems to use SMTP
> technology, at least in part).

I have considered it.  But if I haven't said it yet,  I think the CBV is a
temporary solution.. It works because it based on backward compliancy.   If
we do a new optimal approach, it won't have a payoff  because again - the
target market - the bad guy - isn't going to comply with new stuff, until we
force the issue.

So the CBV is a "BLACK BOX" Return Path Validator.  The return path is a
requirement  which I don't think will every change.   So as soon as someone
comes out that is better, it is plug-play.

I have 3 drafts in the works. A few things keep occuring that holds me back.
But with one I have briefly talked about in various places and it is based
on focusing in the SMTP TMS (Transaction Management and Security) of the
state machine with plug and play security modules based on the parameters
that exist.

     result = EPV-CONN(IP)
     result = EPV-HELO(IP,CDN)
     result = EPV-MFROM(IP,CDN, RP)
     result = EPV-RCPT(IP,CDN, RP, FP)
     result = EPV-DATA(IP,CDN, RP, FP, PL)

we need to fact the fact that in lieu of a complete revamp (which I doubt),
we need to see there will many proposals, many ideas, and the least that the
SMTP people can do is develope a new set of guidelines that puts allows the
interfacing to occur.

Last yeat I outline how this "SMTP CORE" model can be used to define the SPF
model, the SENDERID model, the CSV model as well as CBV.  So that joe sysop
can use one method he likes and the other guy use somtehing else, and the
interfacing would be standard.

The beauty of this approach is that the CORE will stay, but new emal
authentication ideas will continue to come along. So we can plug and play
with it too.

That is whats missing in my view.

I hope John's new effort for 2821bis/2822bis is real effort to address the
real issues the real world confronts today - the SMTP exploits that feeds
into the email security problems.  But for some reason, I think I might be
getting my hopes too high.

We will never be able to eliminate all the subjective mail content issues.
That will always remain a administrative/user/vendor situation.  But I think
we can sincerely address the automated technical aspects of the transport
system and do so with a high degee of success.

If there is one thing that is common - the problem is universal.  Everyone
has an interest to address the issue.  All we need is a focused direction
and dedicated champions to help make it happen.

> As you know, a lot of legitimate mail is being sent with non-replyable,
> non-verifiable mail addresses. Let me give you two examples why CBV
> would be disastrous for me:
>
>    1. a purchase order acknowledgement for schoolbooks I purchased
>       online for one of my sons; in the message were details about how I
>       could pay for these books.

I understand.  But in my view, this is commercial environment and it would
be prudent of the commericall system to comply with standard SMTP 2821
operations.  So they should be a valid return path - not a bad return path.

I acknowledge there could be an exception, but it is not the rule.   The
problem is we allow the exception to relax the process, thus given us
loopholes that are exploited.

Personally, when I did similar transactions of important, I made sure I
provided before I make the purchase:

a) Either an email address that would be white listed, or
b) I would temporarily or permannent white list the vendor

I usually do -a- because I don't want the vendor to have a permanent address
that isn't related to our relationship.   It also helps see if the vendor is
selling the email address, etc.

Now, I don't expect anyone to do this specific recommmendations and it is
certainly not programmed or documented that this should be done, but it is
all very easily doable with today's software.

Again, if the vendor is serious, supporting SPF will help you authorize
them.

>    2. an invitation from the Dutch tax administration service for my
>       company in which I am told to send in a tax declaration before the
>       end of the month. This electronic declaration is mandatory, if my
>       server would have rejected that message, I would have had a
>       serious problem.

Again, a special relationship.  I don't recommending using CBV should not be
used when a social/'business relationship is established.  You don't need
it.

But in general, for the unsolicited anonymous email from the good person,
the CBV is based on the premise that the Return Path is valid and correct
from good systems, and it usually is.

Why would a good system use a bad address?

Can a good system be broken?

Yes, it is possible.  If this was even 5% possibility on a regular basis - I
would dump the CBV,  but think about that.

If the CBV is that unreliable because the 5% of all good systems have bad
return paths, then that pretty says that the bounce system is unreliable as
well and the return path is pretty much useless.

Anyway, thanks for your message.  I would like to know what happen with the
RCPT TO delay.   Will increasing it to 2 minutes do it?  I guess I can
afford to do this because you would be the exception, but then again, I can
easily white list you and the issue is mute.

Thanks

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

Date: Tue, 28 Jun 2005 18:40:54 -0400
From: Keith Moore <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Bounce/System Notification Address Verification
Sender: [email-masked]

> >BUT with 100% without of doubt, no SMTP level false positives that did not
> >have a meaningful reason.
> 
> Excuse me. On March 11, 2004 your server rejected a message of me with 
> perfectly legal envelope from address. Part of the message header:
> 
> > Date: Thu, 11 Mar 2004 19:48:02 +0100
> > From: "Rolf E. Sonneveld" <[email-masked]>
> > Subject: Re: Microsoft Patent - Re: New Internet Draft:
> >  draft-duerst-archived-at-00.txt
> > In-reply-to: <00dd01c40794$478ec670$04f1a8c0@taiwai>
> > To: Tim Kehres <[email-masked]>
> > Cc: Nathaniel Borenstein <[email-masked]>,
> >  Hector Santos <[email-masked]>,
> >  Martin Duerst <[email-masked]>, [email-masked]
> 
> 
> If I remember correctly your CBV rejection had to do with limited 
> bandwidth on my side (yes, I live in Europe and bandwidth in Europe may 
> still be an issue for small companies). Your CBV system failed to verify 
> my mail address (the same address as this very message has), but on that 
> same day I received 179 messages in my mailbox, associated with that 
> same mail address. Furthermore my server tried to send the message for 
> several days, but finally gave up. So the CBV for this message must have 
> encountered the same problem for several days, in which I was able to 
> receive hundreds of messages from the Internet.

This very closely matches the experience I've had with using SMTP-based
CBV.

> This brings me back to the topic for which this mailing list does exist: 
> SMTP. If CBV is one of the possibile ways to fight spam, the use of it 
> should have been documented in some RFC to prevent all sorts of 
> interoperability problems. Such a document on CBV should contain things 
> like:
> 
>     * timeout values for the various CBV commands
>     * mail addresses for which a CBV should not be done (only <>, not
>       postmaster@domain, not mailer-daemon@domain etc., or?)
>     * how to treat domains names (just use MX technology?) to find out
>       against which host to verify
>     * what to do if there is no MX record, but there is an A record
>       (operate the same way as 2821?)
>     * what to do if an MX points to 127.0.0.1
>     * what to do if the envelope from address points to one of your own
>       servers (for small enterprises you can reject such messages, but
>       for large scale environments you can't do that, think e.g. of
>       mailing list messages which come back from the Internet with your
>       domain)
>     * how to deal with situations where primary MX host is down,
>       secondary is up, secondary does not know which address is valid
>       and which is, outbound MTA suffers from CBV because primary MX is
>       down)
>     * etc. etc.
> 
> So let me suggest you write this document and then send it to ietf-smtp 
> for review (I think ietf-smtp is appropriate, as CBV seems to use SMTP 
> technology, at least in part).

I've been thinking about writing a document on address verification
anyway, because there are lots of errors made by web servers (for
instance) that don't do a proper parse of the address.  Use of CBV
would fit into such a document.

Keith

Date: Tue, 28 Jun 2005 18:36:42 -0400
From: Keith Moore <[email-masked]>
To: "Hector Santos" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Bounce/System Notification Address Verification
Sender: [email-masked]

> > Personally I don't bounce mail from you - instead I file it into an
> > appropriately-named folder in case I realize that there's a need to read
> > or respond to something you've said.
> 
> Thanks for the admission. It shows malicious intent to create harm and
> create chaos whenever it suits you.   

No, it shows a desire to avoid responding to every bit of
misinformation and poor advice you send out.  Rather than reading all
of your mail and being tempted to respond to all of it, I generally
avoid reading your mail and thus avoid the temptation to respond to
it.  I generally make exceptions to this only when I somehow get in the
loop (maybe because you've responded to a thread that I was
participating in), or when I realize you've made some exceptionally
egregious recommendation.

> > Everyone in this business gets to succeed or fail based on his reputation.
> 
> Damn right and we have a EXCELLENT reputation in the commercial Online
> Hosting Mail and File distribution, top of the line, and have been for over
> 25+ years.  

How nice for you.  Rest assured that I'm not going to try to take any
of your customers away.  However I will not hesitate to disagree
publicly with you if you say something that I disagree with,
particularly if it seems like your advice could do harm if it were
followed.  If your customers read this list (which I doubt) or find its
archives on the net (somewhat more likely) then they will learn of
these criticisms and the reasons for them.  If it happens that they
choose other vendors' products next time, so much the better for them,
but that's not why I'm bothering to argue with you.

> > You and your company are no more immune from criticism than anyone
> 
> You are correct 100%. Criticism is one things. Lies are not.  Your criticism
> that attacks our integrity must be based on undisputable *facts*.  You have
> outrighted demeaned me personally, my company, my products, my customers on
> numerous occassions over the last 2+ years with statements of unproven fact
> for one purpose only.  To harm me. 

My purpose is to limit the amount of harm you do to Internet mail, not
so much by your products (as they have little market penetration) but
by your poor advice in this forum.

> This includes encouraging others to do the same with censorship.

I'm afraid I don't know what you're talking about here. 

> Even then I have tried publically and privately ask you on many repeated
> attempts to stop the personal attacks.  I've tried to befriend you but you
> kept the personal attacks going.

For the most part, these aren't personal attacks, they're arguments
against statements that you have made and based on observations of the
behavior of software that presumably reflects your products.  You may
take them personally, but they're technical arguments - and technical
arguments are the purpose of this forum.  

Now of course when list participants start trying to back dubious
technical points by making claims about their superior knowledge or
experience, they're inviting attacks along those lines. But if they
stick to arguments based on analysis of the protocols and/or observed
behavior, without trying to impress us with their credentials, the rest
of us will respond with counterarguments based on analysis or
observatins. 

There are several people on this list with a vast amount of experience,
but they don't generally feel the need to tout it.  Anybody, no matter
how experienced, can still learn from this discussion if he doesn't let
his ego get in the way.

Keith

Date: Wed, 29 Jun 2005 00:28:59 +0200
From: "Rolf E. Sonneveld" <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification
To: Hector Santos <[email-masked]>
Cc: [email-masked], Keith Moore <[email-masked]>, [email-masked]
Reply-to: [email-masked]
Organization: Sonnection B.V.
Sender: [email-masked]

>>(Anybody got one? ;)
>>    
>>
>
>You don't have to ask anyone.  There is no doubt we have false positives but
>they are ADDRESSED 100%,   For whatever reason the false positive exhibited
>itself, it was probably a bug or some tight administrative LEVEL filter.
>
>BUT with 100% without of doubt, no SMTP level false positives that did not
>have a meaningful reason.
>  
>

Excuse me. On March 11, 2004 your server rejected a message of me with 
perfectly legal envelope from address. Part of the message header:

> Date: Thu, 11 Mar 2004 19:48:02 +0100
> From: "Rolf E. Sonneveld" <[email-masked]>
> Subject: Re: Microsoft Patent - Re: New Internet Draft:
>  draft-duerst-archived-at-00.txt
> In-reply-to: <00dd01c40794$478ec670$04f1a8c0@taiwai>
> To: Tim Kehres <[email-masked]>
> Cc: Nathaniel Borenstein <[email-masked]>,
>  Hector Santos <[email-masked]>,
>  Martin Duerst <[email-masked]>, [email-masked]

If I remember correctly your CBV rejection had to do with limited 
bandwidth on my side (yes, I live in Europe and bandwidth in Europe may 
still be an issue for small companies). Your CBV system failed to verify 
my mail address (the same address as this very message has), but on that 
same day I received 179 messages in my mailbox, associated with that 
same mail address. Furthermore my server tried to send the message for 
several days, but finally gave up. So the CBV for this message must have 
encountered the same problem for several days, in which I was able to 
receive hundreds of messages from the Internet.

I suspect the timeout values you use (or used) for your CBV are set too 
small to be useable in the real world of the Internet. I reported this 
false positive to you, but you blamed my system for being unresponsive. 
What are the timeout values for your CBV connections, i.e. primary 
connection setup timeout, timeout for EHLO/HELO, timeout for MAIL FROM 
and timeout for RCPT TO?

This brings me back to the topic for which this mailing list does exist: 
SMTP. If CBV is one of the possibile ways to fight spam, the use of it 
should have been documented in some RFC to prevent all sorts of 
interoperability problems. Such a document on CBV should contain things 
like:

    * timeout values for the various CBV commands
    * mail addresses for which a CBV should not be done (only <>, not
      postmaster@domain, not mailer-daemon@domain etc., or?)
    * how to treat domains names (just use MX technology?) to find out
      against which host to verify
    * what to do if there is no MX record, but there is an A record
      (operate the same way as 2821?)
    * what to do if an MX points to 127.0.0.1
    * what to do if the envelope from address points to one of your own
      servers (for small enterprises you can reject such messages, but
      for large scale environments you can't do that, think e.g. of
      mailing list messages which come back from the Internet with your
      domain)
    * how to deal with situations where primary MX host is down,
      secondary is up, secondary does not know which address is valid
      and which is, outbound MTA suffers from CBV because primary MX is
      down)
    * etc. etc.

So let me suggest you write this document and then send it to ietf-smtp 
for review (I think ietf-smtp is appropriate, as CBV seems to use SMTP 
technology, at least in part).

As you know, a lot of legitimate mail is being sent with non-replyable, 
non-verifiable mail addresses. Let me give you two examples why CBV 
would be disastrous for me:

   1. a purchase order acknowledgement for schoolbooks I purchased
      online for one of my sons; in the message were details about how I
      could pay for these books.
   2. an invitation from the Dutch tax administration service for my
      company in which I am told to send in a tax declaration before the
      end of the month. This electronic declaration is mandatory, if my
      server would have rejected that message, I would have had a
      serious problem.

/rolf

To: Hector Santos <[email-masked]>
Cc: Keith Moore <[email-masked]>, [email-masked]
Subject: Re: Bounce/System Notification Address Verification 
From: [email-masked]
Date: Tue, 28 Jun 2005 18:13:21 -0400
Sender: [email-masked]

--==_Exmh_1119996801_3764P
Content-Type: text/plain; charset=us-ascii

On Tue, 28 Jun 2005 16:55:38 EDT, Hector Santos said:

> As it was pointed out on numerous occasions, you are black listed on our
> systems.  We dont' feed trolls reasons to learn how to get around it.
> 
> > Personally I don't bounce mail from you - instead I file it into an
> > appropriately-named folder in case I realize that there's a need to read or
> > respond to something you've said.
> 
> Thanks for the admission. It shows malicious intent to create harm and
> create chaos whenever it suits you. 

And your blacklisting him shows what, exactly?

> be demeaned and defamed.  We are #1 in the online hosting market from
> hobbiest, small, corporate to government, and you don't get there with
> dubious software and system engineering and designs, poor support
> consideraiton, poor quality, non-compliant software as you have stated on
> numerous occassions over the last two years.

So how *do* you compare, sizewise, to the guys at Rackspace and Interland?

--==_Exmh_1119996801_3764P
Content-Type: application/pgp-signature

--==_Exmh_1119996801_3764P--

From: "Hector Santos" <[email-masked]>
To: "Keith Moore" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification
Date: Tue, 28 Jun 2005 16:55:38 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

----- Original Message -----
From: "Keith Moore" <[email-masked]>

> > Keith is filtered in a black list - an administrative level policy.
Instant
> > notification conforms with US ECPA provisions.
>
> Here's the message I'm getting from your server:
>
> <[email-masked]>: host mail.winserver.com[208.247.131.9] said: dIn
???
>     550 Return Path not verifiable. (in reply to RCPT TO command)

As it was pointed out on numerous occasions, you are black listed on our
systems.  We dont' feed trolls reasons to learn how to get around it.

> Personally I don't bounce mail from you - instead I file it into an
> appropriately-named folder in case I realize that there's a need to read
or
> respond to something you've said.

Thanks for the admission. It shows malicious intent to create harm and
create chaos whenever it suits you.   This has been your undenialable modus
operandi towards me for over 2 years now.  There is indisputable proof that
that once you begin your attack,  the thread and mail conversations goes
down the drain.  It has happen with every thread I've participated or
started with unwarranted attacks at me or my products.   ENUF!  GROW UP
ALREADY!

> > Nothing you will be able to prove that we are RFC x822 or RFC x821
> > non-compliant. NOTHING and claiming without proof will cause us business
> > harm.

> Everyone in this business gets to succeed or fail based on his reputation.

Damn right and we have a EXCELLENT reputation in the commercial Online
Hosting Mail and File distribution, top of the line, and have been for over
25+ years.  A reputation based on ethics and moral values and doing the
right thing for my customers.  A reputation I cherish and will not allow to
be demeaned and defamed.  We are #1 in the online hosting market from
hobbiest, small, corporate to government, and you don't get there with
dubious software and system engineering and designs, poor support
consideraiton, poor quality, non-compliant software as you have stated on
numerous occassions over the last two years.

> You and your company are no more immune from criticism than anyone

You are correct 100%. Criticism is one things. Lies are not.  Your criticism
that attacks our integrity must be based on undisputable *facts*.  You have
outrighted demeaned me personally, my company, my products, my customers on
numerous occassions over the last 2+ years with statements of unproven fact
for one purpose only.  To harm me.  This includes encouraging others to do
the same with censorship.

Even then I have tried publically and privately ask you on many repeated
attempts to stop the personal attacks.  I've tried to befriend you but you
kept the personal attacks going.

You can disagree, tell me I am wrong, dispute whatever I say, hopefully
showing good reasons, comment or whatever suits you in the course of public
mail conversations.  I have thick skin.

But I am going to ask you one final time: DO NOT DEFAME AND TORT MY PERSON,
MY COMPANY IN PUBLIC AGAIN.  PLEASE REFRAIN FROM PERSONAL ATTACKS.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

To: Hector Santos <[email-masked]>
Cc: Keith Moore <[email-masked]>, [email-masked]
Subject: Re: Bounce/System Notification Address Verification 
From: [email-masked]
Date: Tue, 28 Jun 2005 16:07:48 -0400
Sender: [email-masked]

--==_Exmh_1119989267_3764P
Content-Type: text/plain; charset=us-ascii

On Tue, 28 Jun 2005 14:55:04 EDT, Hector Santos said:
> From: <[email-masked]>
> > Given the number of times you've said "We do it this way, therefore the
> > rest of you should"
> 
> I have NEVER said such a statement. You can't prove it.  I never have and
> NEVER will because it isn't my character to do so.  If that is how you wish
> to read it, I can't help that. But I have NEVER, EVER, EVER told anyone in
> my entire software and product engineering and development carries "to do it
> may way."

So you *havent* offered your insight and suggestions to your engineering team,
and suggested that they are the way to take the product?  If you haven't, what
sort of leadership *is* that?   I have people coming into my office all the
time looking for design advice, precisely *because* they will get told exactly
how I think things should work.  Presumably my suggestions result in deployable
systems, because they keep coming back.

> I am providing my own insights. That's it.  It is very valuable insight
> whether you care to believe that or not.

And that *isn't* telling the rest of us on the list that you believe it should
be done that way?  And why are you telling *us*, if you don't even tell your
own engineering teams? ;)

Also, a large portion of your "insight" is only valuable *because* it's a fringe
non-standard way of doing things.  Something that is of benefit to *your*
several thousand customers, when they comprise less than 1 percent of the millions
of mail servers and close to a billion (or are we over that now) e-mail users,
will probably *NOT* provide any benefit once it becomes widespread enough for
black hats to code a workaround for....

> > with little or no consideration of what circumstances
> > caused the codifying of standards sections you find inconvenient,

> I am not BREAKING ANY STANDARD whatsoever.

Read *carefully* - I didn't say you were breaking a standard, I said you find
sections of the RFCs inconvenient without thinking about why those sections are
the way they are (usually, it's because other people have other configurations than
what you and your customers have....)

> BUT with 100% without of doubt, no SMTP level false positives that did not
> have a meaningful reason.

OK.. So you *do* on occasion bounce valid mail because you feel like it.

> Keith is filtered in a black list - an administrative level policy.  Instant
> notification conforms with US ECPA provisions.

OK.. So you filter Keith...

> Finally, this isn't going excuse all the defamation and tort attacks and
> call for censorship attacks I have experience from Keith. I won't have a
> problem proving this.

and complain when Keith suggests the same for you.  And I don't remember Keith
bringing up "defamation and tort attacks" - that seemed to be your mail.

--==_Exmh_1119989267_3764P
Content-Type: application/pgp-signature

--==_Exmh_1119989267_3764P--

Date: Tue, 28 Jun 2005 15:32:34 -0400
From: Keith Moore <[email-masked]>
To: "Hector Santos" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Bounce/System Notification Address Verification
Sender: [email-masked]

> I am not BREAKING ANY STANDARD whatsoever.  I am maximizing whatever is
> necessary to be done within the confines of the specification and the best
> current practice. 

Your practice is anything but "best" or "current".

> Where it is spelled out, it is 100% followed.  Where it
> is ambiguous, you do what is the BEST thing possible to make it work for
> your customers and interfacing with the rest of the world.

The standards don't say "don't cut your arm off" either.  That doesn't
mean it is wise to cut your arm off.

When you make dubious or incorrection assumptions about how the mail
system works and use those assumptions as justification to discard or
bounce mail, you may be within the letter of the standards, but you're
not within the intent of the standards.  

> You don't have to ask anyone.  There is no doubt we have false positives but
> they are ADDRESSED 100%,   For whatever reason the false positive exhibited
> itself, it was probably a bug or some tight administrative LEVEL filter.
> 
> BUT with 100% without of doubt, no SMTP level false positives that did not
> have a meaningful reason.

There is no 100% reliable way of knowing that you have a false positive
without showing the message to a recipient and asking him if it is a
message he would want to receive.  You certainly can't detect such
things based on source IP, MAIL FROM, and RCPT TO.

> Keith is filtered in a black list - an administrative level policy.  Instant
> notification conforms with US ECPA provisions.

Here's the message I'm getting from your server:

<[email-masked]>: host mail.winserver.com[208.247.131.9] said: dIn ???
    550 Return Path not verifiable. (in reply to RCPT TO command)

Now according to RFC 2821 550 is the correct reply code for "Access denied"
but the message "Return Path not verifiable" is misleading at best.    Either
you are rejecting my message due to totally bogus criteria or you are returning
a misleading error message.  If you're really bouncing my mail because you've
blacklisted my return address, a more meaningful text message would be 
appropriate.  If you supported ENHANCEDSTATUS codes a status code of 5.7.1 
"Delivery not authorized, message refused" would also seem appropriate.

Personally I don't bounce mail from you - instead I file it into an 
appropriately-named folder in case I realize that there's a need to read or
respond to something you've said.

> Nothing you will be able to prove that we are RFC x822 or RFC x821
> non-compliant. NOTHING and claiming without proof will cause us business
> harm.

Everyone in this business gets to succeed or fail based on his reputation.
You and your company are no more immune from criticism than anyone 
else - though your tendency to concurrently make dubious statements 
and claim superiority for your products does make you a more tempting 
target.   Of course the point of such criticism isn't to bash any one particular
person or company but to point out examples of harmful practices that 
need to be discouraged - not just in your products but in everyones'.

Keith

From: "Hector Santos" <[email-masked]>
To: "Tony Finch" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification 
Date: Tue, 28 Jun 2005 15:20:21 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

From: <[email-masked]>

> You haven't demonstrated that Verizon's implementation is flawed in this
way.

> OK.. I spell it out in excruciating detail:

> Verizon presents me with
> MAIL FROM:<[email-masked]>

> I do a CBV on MAIL FROM, same as Verizon, and send them a
> connection that starts MAIL FROM:<[email-masked]> -
> they see that mail from, and do what?

Then your implementation would be incorrect.  You should not use a NULL
because the 2821 behavior is such that it is a bounceable address.

> Absent some additional RFC-mandated rules not in evidence
> (regarding what the MAIL FROM has to look like for a CBV, etc), this
> *WILL* create a loop if it encounters another copy of itself... thus
> the need for a loop-breaking mechanism.

May I suggest a NULL?

Why can't it be possible to cache the attempts?

> Note that for sites with large outbound-SMTP server farms,
> it's *quite* plausible that even a "is it another from the same IP" check
> would fail to stop it before 30 or 40 iterations - and by that time,
> the *first* one would have timed out, permitting the loop to continue
> (note that *failing* to time these out causes a potential DOS)...

Again, cache your attempts.

When this happens in a bad world, they will get black listed and when it
happens in the good world, you will get white list.

> Also, absent a new, as-yet-unRFC'ed SMTP extension, the remote end
> can't just assume that something is a CBV and ignore it -

So why it would even care? Why not just handle it just like any other
connection?  It will have too anyway.

If the CBV is blasting a system with too many calls, I can see where a
remote may assume a havest attack.   But again, if your system needs to call
back a remote host on a regular basis, then you white list to avoid the
issue.

If you are talking about some identification, then you are talking about
something new which will probably be exploited or not used by the target
malicious senders.   CBV is based on legacy compliancy.  Nothing new is
required.  That is why it works.

> to do so
> would allow a spammer to send you a MAIL FROM/RCPT TO on a
> first connection, then once the callback shows up, use *that*
> information to create what looks like a "callback to a callback",
> but proceed to the DATA step. Whoops.. ;)

You are going to have to explain that line of thought..

Spammers starts a session:

     MAIL FROM: <spammer>
     RCPT TO: <local user>

CBV is started before RCPT TO response is issued:  At the spammer host:

     MAIL FROM: <>
     RCPT TO: <spammer>

What happens now?  Spammer does a call back to where?

It seems that you stuck on that idea that the CBV is the only method
implemented to validate a sender.

You need to elimininate other considerations first before using it.  Such as
RBL, SPF, Local Domain spoofing, etc.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

From: "Hector Santos" <[email-masked]>
To: "Tony Finch" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification 
Date: Tue, 28 Jun 2005 14:58:39 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

----- Original Message -----
From: <[email-masked]>
To: "Tony Finch" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, June 28, 2005 12:41 PM
Subject: Re: Bounce/System Notification Address Verification

> The first rule of any protocol is that it has to interoperate with itself.
> The fact that this design *is* prone to disastrous loops when it
encounters
> other CBV systems with similar design flaws shows that the concept is
flawed.

No does not show the concept is FLAWED, it shows the implementation is
flawed.

Two different things.

To state the concept of a CBV is flawed is to state the BOUNCE operation is
flawed as well because there is no trust on the validity of the return path.

So by your thinking:

- why have a bounce concept at all?

- why even have a bounce requirement in the specification?

With your thinking, the return path entity is useless.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

From: "Hector Santos" <[email-masked]>
To: <[email-masked]>
Cc: "Keith Moore" <[email-masked]>, <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification 
Date: Tue, 28 Jun 2005 14:55:04 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

----- Original Message -----
From: <[email-masked]>

> Given the number of times you've said "We do it this way, therefore the
> rest of you should"

I have NEVER said such a statement. You can't prove it.  I never have and
NEVER will because it isn't my character to do so.  If that is how you wish
to read it, I can't help that. But I have NEVER, EVER, EVER told anyone in
my entire software and product engineering and development carries "to do it
may way."

I am providing my own insights. That's it.  It is very valuable insight
whether you care to believe that or not.

> with little or no consideration of what circumstances
> caused the codifying of standards sections you find inconvenient,

I am not BREAKING ANY STANDARD whatsoever.  I am maximizing whatever is
necessary to be done within the confines of the specification and the best
current practice.  Where it is spelled out, it is 100% followed.  Where it
is ambiguous, you do what is the BEST thing possible to make it work for
your customers and interfacing with the rest of the world.

> I think he's got you here as well...

I disagree with you 100%.  But of course, I understand why you may think so.

>> Maybe if you fixed your mail system to work according to
>> standards rather than your imagination you wouldn't attract such
>> criticism.

> This one is borderline.  However, I'd *strongly* recommend not starting
any
> "defamation and tort legal action" unless you are *really* sure that
*nobody*
> is able to produce a copy of an RFC-compliant message that was rejected by
any
> mail system under your control at the time...

> (Anybody got one? ;)

You don't have to ask anyone.  There is no doubt we have false positives but
they are ADDRESSED 100%,   For whatever reason the false positive exhibited
itself, it was probably a bug or some tight administrative LEVEL filter.

BUT with 100% without of doubt, no SMTP level false positives that did not
have a meaningful reason.

In fact, Julian Mehlne (SPF) just reported what seems to false positive and
a possible bug with our SPF processor. I bring this up because it has to do
with the MX expander and his specific SPF record.   I'm looking into it as
we speak.

If a bug (and I'm sure it is), it will be fixed.   No big deal.

But nothing due to NON-COMPLIANCE.

Keith is filtered in a black list - an administrative level policy.  Instant
notification conforms with US ECPA provisions.

100% support for BOUNCE notifications, if necessary. No NUL BIN DUMPING.
Conforms with US ECPA provisions.

Nothing you will be able to prove that we are RFC x822 or RFC x821
non-compliant. NOTHING and claiming without proof will cause us business
harm.

And you find something - GREAT - all the better.  I have a thick skin. We
fix it and move on.

Finally, this isn't going excuse all the defamation and tort attacks and
call for censorship attacks I have experience from Keith. I won't have a
problem proving this.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

From: "Hector Santos" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification 
Date: Tue, 28 Jun 2005 14:37:47 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

From: <[email-masked]>

On Tue, 28 Jun 2005 11:21:02 EDT, Hector Santos said:

> (Please feel free to re-cite material that is *directly*
> relevant to the *specific* point under discussion, namely the
> concept of skipping a postmaster@ on a CVB...)

I thought I made sufficient comments about it to make it clear
was not a standard, but rather an implementation detail pretty
much like most things that fit within the "standard." already
in place.  (Don't quote/comment this. There is more below).

In addition, it should go without saying your personal opinion on
this long time debate of CBV.  From my perspective, you seek not
to consider the proof of concept regardless if it was perform via
CBV or not.

So before any agreement can be reached, there more be atleast a
common agreement the Return Path is a an veriable item.  If you
don't believe that, there isn't going to be more agreement on
anything else.

On the other hands, if you do believe the proof of concept
and question just the CBV method, then I can understand fully
what your concerns here 100%.

Yet I disagree on the reasons why it should be considered or
to use completed throw it out without exploration.

We do have it implemented Iso  can relate to what is the
experiences.  Not just on my personal support site, but among
thousands of customers using it who will be the last set of
people I would introduce a questional concept.

This is not a "tool" for just my box.  You need to take into
account that there has been a tremendous amount of field testing
prior to the official release nearly 2 years ago.

With that said, I will more than happy to answer your questions.

On Mon, 27 Jun 2005 21:10:38 EDT, Hector Santos said:

> > In regards to a CBV,  a postmaster@domain is skipped.

> a) This is codified in a standard, where, exactly?

> A perfectly valid question regarding a CBV - is there any
> standard that says a postmaster is skipped?  If not, you're
> arguing from "one/several implementations happen to do it that
> way", and will need to justify why this behavior is done.

You are correct. A good question. But try to see it as I read it.
You and I know perfectly well, there is no standard because there
is no RFC or draft specification for a CBV.  So I have a problem
with this statement.  You can say the same for many non-standard
work that fits into the SMTP protocol.

So we are talking about specific implementation details and our
specific engineering principle is to do it with the goal of
making it fit into the SMTP framework with maximum compatibility
considerations.

Ok, all I can do is spell out out implementation and the
justifications for its logic.  Is that sufficient enough?

First, the basic premise of the CBV is based on the idea that the
Return Path is a verfiable item. It is important item because its
role as a bounce address for non-delivery mail.

Second, it was not for the first that over 60-80% of the
transactions use a bad return path, we would not bother. If it
was 10% to maybe 30%, we would probably not bother. But the fact
is, it is by far the majority of transactions.  This is not use
our stats, but industry stats.

The HELO spoofing is about 12-15% by our estimates.  However, in
general, since there is history of good reason for having a
incorrect client machine name, for example MUAs using netbios
computer names, in my view, there is no current good reliable way
to do a helo validator. The payoff is not high at the moment
because there is no requirement to have this valid for mail
operation unlike the return path where there is a mail operation
requirement for it to be valid.

So the payoff is high to explore a return path validator. The
tradeoffs, if any, are significant.

> b) This provides spammers a easy way out by sending with MAIL
> FROM:<postmaster...'

> Particularly in light of the fact that the scheme has a big
> "SPAMMERS, DO THIS TO EVADE" hanging all over it...

Independent of spam considerations, POSTMASTER@DOMAIN is used at
MAIL FROM.  Thats a given.

How much by spammers?  I would have to do a report generation
of my 2 years of daily recorded stats.

The issue is should it be used for RETURN PATH VALIDATION?

The main reason we skip it was because, if I remember, there was
an Exim CBV implementation (Exim calls it CallOut or something to
that effect) that was using POSTMASTER for the call out Mail
From: address.

So as you would correctly suspect, since we were not original
skipping the postmaster address for verification, we had 2-3
level CBV loopback if I remember.

So I remember talking with the administrator and we both agreed
that a NULL return path was better.

Nonetheless, I still went ahead and added the CBV option in our
implementation to avoid future postmaster loopbacks:

   SkipPostMaster True  ; If mail from postmaster, skip CBV

In my view, this is safer and make it more compliant with
standard SMTP BOUNCE operations after the transaction is
accepted.  However, this is not possible because we do use a SMTP
level RCPT validation so that bounces are not possible at this
level.

So it is only optionally skipped for CBV purposes.

Also, the admin had the option to define the CBV MAIL FROM:
address to use:

   SapMailFrom  <>      ; address used for MAIL FROM

This came into play during early R&D to explore how remote systems
reacted to NULL return paths RCPT checks.

This was related to the issue I think Verizon came across whether
they use an alternate mail from after a NULL attempt.

I don't particular agree with this method because of what we learned
is that you don't use the NULL, then you do run the risk of a loopback.

So althought the option is still there, it is not recommended to change
it.

Finally, remember this. For my design consideration, I am firmly
aware it would be there is high CBV no trust issue with PASS results.

So the goal is to mustly address the Bad Host and false result and
the small open relay test.  If that doesn't give a result, than you
throw up your hands, accept the transaction and move on.   The CBV
did the best it can do.

Fortunately, the payoff has proved to be high because again, the
majority of the transactions are indeed bad.

> c) Wander over to www.rfc-ignorant.org and see all the
>    sites that *don't* properly support 'postmaster', so the
>    assumption that "We won't check it because we "know" it's
>    operational" is severely b0rked.

> Combined with the fact that enough sites in fact manage to *not*
> support "postmaster" in violation of the RFCs that automatically
> white-listing it is a bad idea.

Ok, did we misunderstand, did the above answer this?

POSTMASTER is indeed annoyed.  It is skipped for CBV purposes only.

> So we have a non-standard practice, combined with an obvious
> exploit, and of dubious actual usefulness in a real world that
> has difficulty following the *current* standards.  If you have a
> concrete technical explanation of why it's *still* a good idea in
> face of all that, let us know....

Like I said, to me, this is more of the status quo statements
that existed in past CBV debates.  It is more on the insulting
side and more on 'stubborness side'

It seems that no matter what I say, it doesn't matter.  There is
no benefit of the doubt, there is no consideration whatsoever for
the technical experiences we do have.  Like we don't matter.

Thats offensive to me, but I am not a hobbiest. This is a
commercial system and I have thousands of customers using our
mail system, which is just about 20-25% of our business (and
growing). But we over hundreds of thousands of customers using
our main product where the mail system is fundamental part of it.
It just may not be the part the customer is using.

That is absolutely NOT to say your comments and experiences is not
heeded.  I do learn from everyone here. Trust me.  We are
constantly updating and improviing the system based on the BCP
extracted from the comments and discussions, etc.  In fact, you
helped tremendously with our DNS client implementation MX
expansion logic for the SPF processor. Remember?

But to throw out accusations, that we are non-standard,
introducing exploits, using stupid and dubious considerations
with no practical insight with real world operations, well, my
friend, that is insulting to me.

It leaves me three choices:

- Ignore you
- Defend myself
- Try again to explain

I try to take the high road and do the latter, but it typically
does not matter with people, I am sorry to say, like yourself.
You made your might up.

But you see, I am optimist, and I have been at this cyberspace
communication game for over 30 years and I can see the different
in who is who.  Its not hard to see.

Anyway, I hope the details I provided above is sufficient.

I can summarize what we do with maximum compability
considerations:

- Return Path is a verifiable item per RFC 2821.

- Applies only for anonymous final destination transactions.

- A suite of Sender Authentication protocols called WCSAP is
  used check the transaction parameters.  CBV is the final
  check.

- WCSAP is called after the RCPT TO is determined to be a valid
  local user for an non-authorized session only.

- WCSAP is skipped when MAILFROM is <> or POSTMASTER@DOMAIN
  The postmaster skip is optional.

- A fast White/Black rule based filter table is applied,

- RBL is applied

- LMAP is applied (DMP, SPF, CALLERID)

- CBV is used as a final check

- CBV performs a 100% SMTP Client callback with the
  exception of having smaller timeouts.

- NXDOMAIN, BAD connects are rejects.

- STATE machine problems are rejects.

- CBV uses NULL mail from (default), to test sender return path.

- CBV uses an open relay test for random address acceptance.

Other stuff:

- CBV has VRFY option to use instead of RCPT. If enabled,
  a non-supported VRFY fallback to RCPT checking.

- CBV uses NOOP to provide a identification "idea".

-- 
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

From: "Hector Santos" <[email-masked]>
To: "Tony Finch" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification 
Date: Tue, 28 Jun 2005 14:30:16 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

----- Original Message -----
From: "Tony Finch" <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification

> On Tue, 28 Jun 2005 [email-masked] wrote:
> >
> > The first rule of any protocol is that it has to interoperate with
itself.
> > The fact that this design *is* prone to disastrous loops when it
encounters
> > other CBV systems with similar design flaws shows that the concept is
flawed.
>
> You haven't demonstrated that Verizon's implementation is flawed in this
way.
>

Tony,

Can you tell us about Exim's "Callout" implementation? and your personal
experiences? and also how others use it? and issues encountered?

Thanks

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: Bounce/System Notification Address Verification
Date: Tue, 28 Jun 2005 13:26:19 -0400
Cc: Tony Finch <[email-masked]>, [email-masked]
Sender: [email-masked]

On Tue June 28 2005 13:04, Tony Finch wrote:
> 
> On Tue, 28 Jun 2005 [email-masked] wrote:
> >
> > The first rule of any protocol is that it has to interoperate with itself.
> > The fact that this design *is* prone to disastrous loops when it encounters
> > other CBV systems with similar design flaws shows that the concept is flawed.
> 
> You haven't demonstrated that Verizon's implementation is flawed in this way.

I believe this was discussed at length on the ASRG list ca. March 2005:
http://www1.ietf.org/mail-archive/web/asrg/current/mail13.html

It was also alluded to here not so long ago...

To: Tony Finch <[email-masked]>
Cc: [email-masked]
Subject: Re: Bounce/System Notification Address Verification 
From: [email-masked]
Date: Tue, 28 Jun 2005 13:24:36 -0400
Sender: [email-masked]

--==_Exmh_1119979476_3764P
Content-Type: text/plain; charset=us-ascii

On Tue, 28 Jun 2005 18:04:02 BST, Tony Finch said:
> On Tue, 28 Jun 2005 [email-masked] wrote:
> >
> > The first rule of any protocol is that it has to interoperate with itself.
> > The fact that this design *is* prone to disastrous loops when it encounters
> > other CBV systems with similar design flaws shows that the concept is flawed.
> 
> You haven't demonstrated that Verizon's implementation is flawed in this way.

OK.. I spell it out in excruciating detail:

Verizon presents me with MAIL FROM:<[email-masked]>

I do a CBV on MAIL FROM, same as Verizon, and send them a connection that starts
MAIL FROM:<[email-masked]> - they see that mail from, and do what?

Absent some additional RFC-mandated rules not in evidence (regarding what
the MAIL FROM has to look like for a CBV, etc), this *WILL* create a loop if
it encounters another copy of itself... thus the need for a loop-breaking mechanism.

Note that for sites with large outbound-SMTP server farms, it's *quite* plausible
that even a "is it another from the same IP" check would fail to stop it before
30 or 40 iterations - and by that time, the *first* one would have timed out,
permitting the loop to continue (note that *failing* to time these out causes a
potential DOS)...

Also, absent a new, as-yet-unRFC'ed SMTP extension, the remote end can't just
assume that something is a CBV and ignore it - to do so would allow a spammer to
send you a MAIL FROM/RCPT TO on a first connection, then once the callback shows
up, use *that* information to create what looks like a "callback to a callback",
but proceed to the DATA step. Whoops.. ;)

--==_Exmh_1119979476_3764P
Content-Type: application/pgp-signature

--==_Exmh_1119979476_3764P--

Date: Tue, 28 Jun 2005 18:04:02 +0100
From: Tony Finch <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: Bounce/System Notification Address Verification 
Sender: [email-masked]

On Tue, 28 Jun 2005 [email-masked] wrote:
>
> The first rule of any protocol is that it has to interoperate with itself.
> The fact that this design *is* prone to disastrous loops when it encounters
> other CBV systems with similar design flaws shows that the concept is flawed.

You haven't demonstrated that Verizon's implementation is flawed in this way.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.

To: Hector Santos <[email-masked]>
Cc: Keith Moore <[email-masked]>, [email-masked]
Subject: Re: Bounce/System Notification Address Verification 
From: [email-masked]
Date: Tue, 28 Jun 2005 12:59:32 -0400
Sender: [email-masked]

--==_Exmh_1119977972_3764P
Content-Type: text/plain; charset=us-ascii

On Tue, 28 Jun 2005 11:54:55 EDT, Hector Santos said:

> If you disagree with my comments, opinion, etc,  fine.  Explain, show or
> throw in your own opinions, even say I'm wrong,  but the PERSONAL ATTACKS
> HAS GOT TO STOP!

The closest I can see to a "personal attack" in Keith's note is:

>> Hey, you're the one blocking perfectly legitimate mail using poor
>> criteria,

Keith's expressing a tautology here - if it blocks legitimate mail, it's
a poor criterion by definition.

>>           and meanwhile touting the superiority of your products and
>> expertise as justification for why everyone should do things your way.

Given the number of times you've said "We do it this way, therefore the
rest of you should" with little or no consideration of what circumstances
caused the codifying of standards sections you find inconvenient, I think
he's got you here as well...

>> Maybe if you fixed your mail system to work according to
>> standards rather than your imagination you wouldn't attract such
>> criticism.

This one is borderline.  However, I'd *strongly* recommend not starting any
"defamation and tort legal action" unless you are *really* sure that *nobody*
is able to produce a copy of an RFC-compliant message that was rejected by any
mail system under your control at the time...

(Anybody got one? ;)

--==_Exmh_1119977972_3764P
Content-Type: application/pgp-signature

--==_Exmh_1119977972_3764P--

To: Hector Santos <[email-masked]>
Cc: [email-masked]
Subject: Re: Bounce/System Notification Address Verification 
From: [email-masked]
Date: Tue, 28 Jun 2005 12:56:57 -0400
Sender: [email-masked]

--==_Exmh_1119977817_3764P
Content-Type: text/plain; charset=us-ascii

On Tue, 28 Jun 2005 11:21:02 EDT, Hector Santos said:
> If you are going to do selective quoting to nitpick and point out whatever
> you want, without reading related comments in the message and/or other
> thread fibers, then I will begin to ignore your replies.

It is generally considered good e-mail etiquette to trim extraneous material,
so that an ensuing thread doesn't keep re-quoting it.  Having said that, I'm
hereby re-quoting the material *YOU* excised, which is the point of this thread:

(Please feel free to re-cite material that is *directly* relevant to the *specific*
point under discussion, namely the concept of skipping a postmaster@ on a CVB...)

On Mon, 27 Jun 2005 21:10:38 EDT, Hector Santos said:

> > > MAIL FROM:<postmaster@domain> means "send bounces to
> > > postmaster@domain", NOT "no bounce needed".
> 
> > In regards to a CBV,  a postmaster@domain is skipped.

> a) This is codified in a standard, where, exactly?

A perfectly valid question regarding a CBV - is there any standard that says
a postmaster is skipped?  If not, you're arguing from "one/several implementations
happen to do it that way", and will need to justify why this behavior is done.

> b) This provides spammers a easy way out by sending with MAIL
> FROM:<postmaster...'

Particularly in light of the fact that the scheme has a big "SPAMMERS, DO THIS
TO EVADE" hanging all over it...

> c) Wander over to www.rfc-ignorant.org and see all the sites that *don't*
> properly support 'postmaster', so the assumption that "We won't check it because
> we "know" it's operational" is severely b0rked.

Combined with the fact that enough sites in fact manage to *not* support "postmaster"
in violation of the RFCs that automatically white-listing it is a bad idea.

So we have a non-standard practice, combined with an obvious exploit, and of
dubious actual usefulness in a real world that has difficulty following the *current*
standards.  If you have a concrete technical explanation of why it's *still*
a good idea in face of all that, let us know....

--==_Exmh_1119977817_3764P
Content-Type: application/pgp-signature

--==_Exmh_1119977817_3764P--

From: "Hector Santos" <[email-masked]>
To: <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification
Date: Tue, 28 Jun 2005 12:49:33 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

----- Original Message -----
From: "Keith Moore" <[email-masked]>
To: "Robert A. Rosenberg" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, June 28, 2005 11:10 AM
Subject: Re: Bounce/System Notification Address Verification

> > OTOH: There is no requirement that the generator of these responses
> > (when presented with a request/need to sent such a message to more
> > than one recipient) create a single copy of the message as opposed to
> > one personally addressed copy per recipient. Creating multiple copies
> > preserves the "Only One Recipient for a 'Mail From <>' message" rule.
>
> what rule is that?  please cite the standard.

Keith,

I don't think there is implicitly stated rule in the RFCs.  A quick review
of RCPT TO related material does not indicate a limit for NULL return paths.

However, it is an administrative option and it exist because the need was
apparent and they asked for it.  So implementations programmed the
administrator local policy option or they began to use what was already
possible for them.

What I am pointing out that that it is being enforce more and more, and the
main reason is because it was being exploited by spammers.

I see two critical points.

First,  if there are conflicts, the limit itself should not be the reason,
but rather the false assumption by an agent that tries to use this to
BROADCAST, not BOUNCE, electronic mail using a NULL return path.

Second,  it isn't an issue unless there is a post-smtp recipient validation
concept that triggers the non-deliverable accepted message bounce
requirement.

For example:

For a dynamic SMTP RCPT checker:

    MAIL FROM: <>
    RCPT TO:  <good user1>
    250 ok
    RCPT TO:  <good user2>
    250 ok
    RCPT TO:  <bad user3>
    451 doesn't exist
    RCPT TO:  <good user4>
    250 ok
    RCPT TO:  <bad user5>
    451 doesn't exist

In a transaction like this,  a non-restrictive system will accept the 3 good
systems.  Some systems will actually count the errors and may abort the
transactions or stop accepted more RCPT TO commands.    Some have limits
altogether.

But what is important here, there is no bouncing, even of the MAIL FROM: was
not NULL.  This is an instant notification concept.

For the post SMTP system

    MAIL FROM: <>
    RCPT TO:  <good user1>
    250 ok
    RCPT TO:  <good user2>
    250 ok
    RCPT TO:  <bad user3>
    250 ok
    RCPT TO:  <good user4>
    250 ok
    RCPT TO:  <bad user5>
    250 ok

We now have 2 bad address and under normal circumstances it will a bounce
consideration.    But there is none due to the NULL return path.

These are the type of abuses you will see from SPAMMERS, not the SORBIG
based bounce-based attackers.

For the SPAMMER, they will use a NULL, POSTMASTER or a BAD or SPOOFED
address..

For the SORBIG-based generation eViruses,  they will not use a NULL return
path, but typically a spoofed address, not bad.

They seek post smtp validation systems, because this gives them a dual tier
distribution:

   - 3 messages, for 3 potential good addresses reaching 3 local users

   - 2 bounces to 1 potentially good sender return path address.

So whether there is or not a "rule" regarding NULL return path RCPT limits,
the reality is what it is and people are addressing this and in my opinion,
it fits the framework better than allowing a open ended NULL broadcasting
concept.   As you said, not every system supports your optional DSN
specification, but even then, the NOTIFY=NEVER modifier will be scrutinized
as a potential exploit.   The SPAMMER may use it.  The SORBIG attacker will
not.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

To: Tony Finch <[email-masked]>
Cc: [email-masked]
Subject: Re: Bounce/System Notification Address Verification 
From: [email-masked]
Date: Tue, 28 Jun 2005 12:41:31 -0400
Sender: [email-masked]

--==_Exmh_1119976890_3764P
Content-Type: text/plain; charset=us-ascii

On Tue, 28 Jun 2005 15:55:27 BST, Tony Finch said:
> On Tue, 28 Jun 2005 [email-masked] wrote:
> >
> > Please note that using the near-universally reviled Verizon method as
> > anything other than an example of how *not* to do it:
> >
> > 19:36:18 C: MAIL FROM:<[email-masked]>
> >
> > Now explain to me why I shouldn't do a CBV on this?
> 
> And if you do, what do you expect to happen? If Verizon calls back in
> response to your callback (i.e. they're doing CBV for email to
> [email-masked]) then they are asking for a disastrous
> callback loop. However this will only occur if your system has the same
> bug.

The first rule of any protocol is that it has to interoperate with itself.
The fact that this design *is* prone to disastrous loops when it encounters
other CBV systems with similar design flaws shows that the concept is flawed.

And I *did* start off with "near-universally reviled" ;)

--==_Exmh_1119976890_3764P
Content-Type: application/pgp-signature

--==_Exmh_1119976890_3764P--

From: "Hector Santos" <[email-masked]>
To: "Keith Moore" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification
Date: Tue, 28 Jun 2005 11:54:55 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

Mr. Moore,

On more than one occasion, I have asked you repeatedly to stop the personal
attacks.  Now, you are pissing me off and if you continue this line of
personal public attacks, I will seek 3rd party action, either thru the IETF
or whatever mechanisms they have in place or seek defamation and tort legal
action against you.

If you disagree with my comments, opinion, etc,  fine.  Explain, show or
throw in your own opinions, even say I'm wrong,  but the PERSONAL ATTACKS
HAS GOT TO STOP!

I don't wish to be wasting time with such nonsense. Please don't push it.
Please STOP!

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

----- Original Message -----
From: "Keith Moore" <[email-masked]>
To: "Hector Santos" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, June 28, 2005 11:08 AM
Subject: Re: Bounce/System Notification Address Verification

>
> > > There is also no reason that a server should refuse multiple RCPT TOs
> > > when given a return path of <>.
> >
> > I believe there is. The majority of good systems do not behave this way,
> > especially when issueing a RANDOM address which is what this thread is
> > about.
>
> An observation that the majority of systems behave a certain way is not
> a good reason for depending on that behavior, as even seldom-used
> functionality can be extremely valuable overall.  Add to that the
> uncertainty involved in measuring "majority" (I doubt that you have
> done enough measurement to make that assertion reliably) and
> "good" (what are your criteria for "good" and why should we accept them
> if they're different than the standards?) and the supposed
> justification disappears completely.
>
> > > Wrong.  There is no prohibition that I'm aware of against using <> for
> > > other purposes, and there are some standards that specifically require
> > > using <> - e.g. MDNs and responses from mail robots, neither of
> > > which are constrained to exactly one recipient.
> >
> > Keith, we were referring (atleast I was) to the fact that they do EXIST
1
> > RCPT limits for a NULL return path.  There are plenty of systems that
work
> > in this mode whether you care to believe that or not.  The conflict you
seem
> > to forget is that your multi rcpt-to/null return path allowance is a
source
> > of spam.
>
> You are wrong about that also.  It is not a source of spam.  While
> failing to permit multiple RCPTs with MAIL FROM <> might allow some
> spam to pass, it also allows legitimate mail to pass.  Using unreliable
> criteria to block mail because it might be spam harms the transparency
> of the mail system and makes it less reliable.
>
> > > But in general, lots of
> > > mail software authors and/or operators are making dubious assumptions
> > > about what kinds of spam countermeasures are reasonable, and those
> > > assumptions conflict with one another far too often.
> >
> > You need to separate 2821 from 2822 (body) Keith if you want to see the
> > light at the end of the tunnel.
>
> I'm very aware of the difference.   Dubious countermeasures are being
> implemented at both layers, and my statement applies equally to both.
>
> > > well, it appears that your mail server rejects a lot of perfectly
valid
> > > mail for other reasons known only to you, so I guess I'm not
surprised.
> >
> > I wish you would stop your own going pot shots at me. It is
non-productive,
> > antagonistic, insulting and quite frankly very tiresome.
>
> Hey, you're the one blocking perfectly legitimate mail using poor
> criteria, and meanwhile touting the superiority of your products and
> expertise as justification for why everyone should do things your way.
> Maybe if you fixed your mail system to work according to
> standards rather than your imagination you wouldn't attract such
> criticism.
>
> Keith
>
>

From: "Hector Santos" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification 
Date: Tue, 28 Jun 2005 11:21:02 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

If you are going to do selective quoting to nitpick and point out whatever
you want, without reading related comments in the message and/or other
thread fibers, then I will begin to ignore your replies.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

----- Original Message -----
From: <[email-masked]>
To: "Hector Santos" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, June 28, 2005 10:31 AM
Subject: Re: Bounce/System Notification Address Verification

a) This is codified in a standard, where, exactly?

b) This provides spammers a easy way out by sending with MAIL
FROM:<postmaster...'

c) Wander over to www.rfc-ignorant.org and see all the sites that *don't*
properly support 'postmaster', so the assumption that "We won't check it
because
we "know" it's operational" is severely b0rked.

From: "Hector Santos" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification 
Date: Tue, 28 Jun 2005 11:16:39 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

----- Original Message -----
From: <[email-masked]>
To: "Hector Santos" <[email-masked]>

> OK, let's throw out support for HELO, because the majority of good systems
> do EHLO.  And throw out 8BITMIME support, only spamming pacific rim sites
> use that in my experience.  Oh, and there' this other feature...

> Equating "The majority don't do that" with "nobody should do that and it
> shouldn't be supported" for a feature that has demonstrable usefulness is
a
> Bad Idea.

I don't believe I implied any of the above, but since you brought it up ...

Isn't that how the IETF works - by consensus?  which today, forgive me if I
am wrong, just expressing what seems to be happening,  isn't really a
majority but rather a few veteran cogs moving to private discussion areas to
define what is in their view the best interest of the world.   Absolutely
nothing wrong with that!  I generally have full faith in experienced people,
and typically I feel common sense prevails.

Now, in regards to the "SPAM PROBLEM."

Do the math: Over 60-80% of all transactions are problematics.  Microsoft
says its over 90%.  We see a 94% rate. YMMV, but there is absolutely no
dispute here of the high volume of non-compliant SMTP transactions.

The spam problem exist primarily because the SMTP process is 100% exploited
in every which way possible  No need to go into details, but it all begins
with its relaxed provisions.You are a smart guy. I don't think I need to go
futher.  Just do the math.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

Date: Tue, 28 Jun 2005 11:10:42 -0400
From: Keith Moore <[email-masked]>
To: "Robert A. Rosenberg" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Bounce/System Notification Address Verification
Sender: [email-masked]

> OTOH: There is no requirement that the generator of these responses 
> (when presented with a request/need to sent such a message to more 
> than one recipient) create a single copy of the message as opposed to 
> one personally addressed copy per recipient. Creating multiple copies 
> preserves the "Only One Recipient for a 'Mail From <>' message" rule.

what rule is that?  please cite the standard.

Keith

Date: Tue, 28 Jun 2005 11:08:54 -0400
From: Keith Moore <[email-masked]>
To: "Hector Santos" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Bounce/System Notification Address Verification
Sender: [email-masked]

> > There is also no reason that a server should refuse multiple RCPT TOs
> > when given a return path of <>.
> 
> I believe there is. The majority of good systems do not behave this way,
> especially when issueing a RANDOM address which is what this thread is
> about.

An observation that the majority of systems behave a certain way is not
a good reason for depending on that behavior, as even seldom-used
functionality can be extremely valuable overall.  Add to that the
uncertainty involved in measuring "majority" (I doubt that you have
done enough measurement to make that assertion reliably) and
"good" (what are your criteria for "good" and why should we accept them
if they're different than the standards?) and the supposed
justification disappears completely. 

> > Wrong.  There is no prohibition that I'm aware of against using <> for
> > other purposes, and there are some standards that specifically require
> > using <> - e.g. MDNs and responses from mail robots, neither of
> > which are constrained to exactly one recipient.
> 
> Keith, we were referring (atleast I was) to the fact that they do EXIST 1
> RCPT limits for a NULL return path.  There are plenty of systems that work
> in this mode whether you care to believe that or not.  The conflict you seem
> to forget is that your multi rcpt-to/null return path allowance is a source
> of spam.

You are wrong about that also.  It is not a source of spam.  While
failing to permit multiple RCPTs with MAIL FROM <> might allow some
spam to pass, it also allows legitimate mail to pass.  Using unreliable
criteria to block mail because it might be spam harms the transparency
of the mail system and makes it less reliable.

> > But in general, lots of
> > mail software authors and/or operators are making dubious assumptions
> > about what kinds of spam countermeasures are reasonable, and those
> > assumptions conflict with one another far too often.
> 
> You need to separate 2821 from 2822 (body) Keith if you want to see the
> light at the end of the tunnel.  

I'm very aware of the difference.   Dubious countermeasures are being 
implemented at both layers, and my statement applies equally to both.

> > well, it appears that your mail server rejects a lot of perfectly valid
> > mail for other reasons known only to you, so I guess I'm not surprised.
> 
> I wish you would stop your own going pot shots at me. It is non-productive,
> antagonistic, insulting and quite frankly very tiresome. 

Hey, you're the one blocking perfectly legitimate mail using poor
criteria, and meanwhile touting the superiority of your products and
expertise as justification for why everyone should do things your way.
Maybe if you fixed your mail system to work according to
standards rather than your imagination you wouldn't attract such
criticism.  

Keith

From: "Hector Santos" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification 
Date: Tue, 28 Jun 2005 10:58:43 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

----- Original Message -----
From: <[email-masked]>

> Please note that using the near-universally reviled Verizon
> method as anything other than an example of how *not* to do it:

Noted, but it is what it is.  In my personal assessment,  verizon,
santronics and many others who have implemented CBV just because we thought
it was a great idea, but because YOU (speaking of the IETF community in
general, are foot dragging or many times, not even then to come up with a
solution to even REDUCE the "email problem."   Commercial outfits need to
service customers and address the issue.  We are not going to wait.

And again, from my perspective, it is the PROOF of CONCEPT that is more
important.  The SMTP BASED CBV may not be the more efficient solution, but
it certainly the only method you have today that is backward compatible.

> 19:36:18 C: MAIL FROM:<[email-masked]>
>
> Now explain to me why I shouldn't do a CBV on this?

You are quite correct.  I don't particular like this Verizon method to test
the concept of whether a NULL is failing a RCPT check.    It is different
from the rest.

As I mentioned, I believe this was because one of the big ISP (aka big SPAM
source) were behaving as such. I can't recall who it was specifically and
whether that practice has change. I am leaning that it was changed as the
started to see more CBV transactions.

But I agree 100% with you.  Yet,  it is not enough to throw out the baby
with the bath water.

When directed at us, you probably noticed the delay in sender verification
until the RCPT TO is determined.  So this isn't an issue.

At worst, if we did do a MAIL FROM call back,  not delay, there would be a
two level CBV.  Not good, I prefer not to see this, but it is not a
perpetual loop-back.

As a said a quite a few times and outlined in my Mail Hosting
Recommendations;  Any sender verification concept with potential overhead
issues such be delayed until it is deemed absolutely necessary.  In this
case, follow the excellent recommendation John Klensin outlined in RFC 2821.
See RFC 2821 Section 3.3:

| 3.3 Mail Transactions
|
|    .....
|
|   .............  Despite the apparent
|   scope of this requirement, there are circumstances in which the
|   acceptability of the reverse-path may not be determined until one or
|   more forward-paths (in RCPT commands) can be examined.  In those
|   cases, the server MAY reasonably accept the reverse-path (with a 250
|   reply) and then report problems after the forward-paths are received
|   and examined.  Normally, failures produce 550 or 553 replies.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

Date: Tue, 28 Jun 2005 15:55:27 +0100
From: Tony Finch <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: Bounce/System Notification Address Verification 
Sender: [email-masked]

On Tue, 28 Jun 2005 [email-masked] wrote:
>
> Please note that using the near-universally reviled Verizon method as
> anything other than an example of how *not* to do it:
>
> 19:36:18 C: MAIL FROM:<[email-masked]>
>
> Now explain to me why I shouldn't do a CBV on this?

And if you do, what do you expect to happen? If Verizon calls back in
response to your callback (i.e. they're doing CBV for email to
[email-masked]) then they are asking for a disastrous
callback loop. However this will only occur if your system has the same
bug.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.

To: Hector Santos <[email-masked]>
Cc: [email-masked]
Subject: Re: Bounce/System Notification Address Verification 
From: [email-masked]
Date: Tue, 28 Jun 2005 10:31:42 -0400
Sender: [email-masked]

--==_Exmh_1119969102_4284P
Content-Type: text/plain; charset=us-ascii

On Mon, 27 Jun 2005 21:10:38 EDT, Hector Santos said:

> > MAIL FROM:<postmaster@domain> means "send bounces to
> > postmaster@domain", NOT "no bounce needed".
> 
> In regards to a CBV,  a postmaster@domain is skipped.

a) This is codified in a standard, where, exactly?

b) This provides spammers a easy way out by sending with MAIL FROM:<postmaster...'

c) Wander over to www.rfc-ignorant.org and see all the sites that *don't*
properly support 'postmaster', so the assumption that "We won't check it because
we "know" it's operational" is severely b0rked.

--==_Exmh_1119969102_4284P
Content-Type: application/pgp-signature

--==_Exmh_1119969102_4284P--

To: Hector Santos <[email-masked]>
Cc: [email-masked]
Subject: Re: Bounce/System Notification Address Verification 
From: [email-masked]
Date: Tue, 28 Jun 2005 10:29:31 -0400
Sender: [email-masked]

--==_Exmh_1119968971_4284P
Content-Type: text/plain; charset=us-ascii

On Mon, 27 Jun 2005 21:10:38 EDT, Hector Santos said:

> I believe there is. The majority of good systems do not behave this way,
> especially when issueing a RANDOM address which is what this thread is
> about.

OK, let's throw out support for HELO, because the majority of good systems
do EHLO.  And throw out 8BITMIME support, only spamming pacific rim sites
use that in my experience.  Oh, and there' this other feature...

Equating "The majority don't do that" with "nobody should do that and it
shouldn't be supported" for a feature that has demonstrable usefulness is a
Bad Idea.

--==_Exmh_1119968971_4284P
Content-Type: application/pgp-signature

--==_Exmh_1119968971_4284P--

To: Hector Santos <[email-masked]>
Cc: [email-masked]
Subject: Re: Bounce/System Notification Address Verification 
From: [email-masked]
Date: Tue, 28 Jun 2005 10:26:37 -0400
Sender: [email-masked]

--==_Exmh_1119968797_4284P
Content-Type: text/plain; charset=us-ascii

On Mon, 27 Jun 2005 20:38:13 EDT, Hector Santos said:

> Verizon.Net is a big ISP and they perform a CBV on every incoming
> unauthorized transactions. But it does it immediately at MAIL FROM.  We wait
> until RCPT TO is determined to reduce the overhead CBV need
> 
> Check out how Verizon.Net does using its MailPass server.

Please note that using the near-universally reviled Verizon method as
anything other than an example of how *not* to do it:

19:36:18 C: MAIL FROM:<[email-masked]>

Now explain to me why I shouldn't do a CBV on this?

--==_Exmh_1119968797_4284P
Content-Type: application/pgp-signature

--==_Exmh_1119968797_4284P--

To: Hector Santos <[email-masked]>
Cc: [email-masked]
Subject: Re: Bounce/System Notification Address Verification 
From: [email-masked]
Date: Tue, 28 Jun 2005 10:17:54 -0400
Sender: [email-masked]

--==_Exmh_1119968274_4284P
Content-Type: text/plain; charset=us-ascii

On Mon, 27 Jun 2005 21:10:38 EDT, Hector Santos said:

> Keith, we were referring (atleast I was) to the fact that they do EXIST 1
> RCPT limits for a NULL return path.  There are plenty of systems that work
> in this mode whether you care to believe that or not.  The conflict you seem
> to forget is that your multi rcpt-to/null return path allowance is a source
> of spam.

No, what *I* said was that since, *in general*, a bounce only has 1 MAIL FROM
to generate RCPT TO's, and there's a lot of idiot mail admins that feel
justified in saying "Since this is true 98% of the time, we will force it
to be true always...."

--==_Exmh_1119968274_4284P
Content-Type: application/pgp-signature

--==_Exmh_1119968274_4284P--

Date: Tue, 28 Jun 2005 13:50:53 +0100
From: Tony Finch <[email-masked]>
To: [email-masked]
cc: Hector Santos <[email-masked]>, IETF-SMTP <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification 
Sender: [email-masked]

On Mon, 27 Jun 2005 [email-masked] wrote:

> On Mon, 27 Jun 2005 12:38:42 EDT, Hector Santos said:
>
> > What is the BCP for allowing multiple RCPT TO when the return path is NULL?
>
> In general, since the message that's sent with the null MAIL FROM generates
> the RCPT TO from the inbound MAIL FROM, and there's only one of those, then
> you can only get one outbound RCPT TO.

However if the return path might have been an alias which expands to more
than one address, and this can reslult in legitimate bounces with more
than one recipient.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: Bounce/System Notification Address Verification
Date: Tue, 28 Jun 2005 08:24:47 -0400
Cc: "Robert A. Rosenberg" <[email-masked]>
Sender: [email-masked]

On Tue June 28 2005 01:42, Robert A. Rosenberg wrote:
> 
> At 16:34 -0400 on 06/27/2005, Keith Moore wrote about Re: 
> Bounce/System Notification Address Verification:
> 
> >Wrong.  There is no prohibition that I'm aware of against using <> for
> >other purposes, and there are some standards that specifically require
> >using <> - e.g. MDNs and responses from mail robots, neither of
> >which are constrained to exactly one recipient.
> 
> OTOH: There is no requirement that the generator of these responses 
> (when presented with a request/need to sent such a message to more 
> than one recipient) create a single copy of the message as opposed to 
> one personally addressed copy per recipient.

You are correct that there is no *requirement*, but sending an MDN to
multiple recipients is explicitly permitted and in fact may be specified
by the sender; RFC 3798:

   mdn-request-header = "Disposition-Notification-To" ":"
             mailbox *("," mailbox)

N.B. multiple MDN recipients may be specified.

Rejecting what is explicitly permitted is probably not a good idea unless
there is some ancillary information or some overriding consideration.

Administratively rejecting specific permitted, useful, non-harmful
information that users have explicitly requested is probably not sound
policy.

> Creating multiple copies  
> preserves the "Only One Recipient for a 'Mail From <>' message" rule.

Where exactly is that "rule" specified?

Date: Tue, 28 Jun 2005 01:42:41 -0400
To: [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification
Sender: [email-masked]

At 16:34 -0400 on 06/27/2005, Keith Moore wrote about Re: 
Bounce/System Notification Address Verification:

>Wrong.  There is no prohibition that I'm aware of against using <> for
>other purposes, and there are some standards that specifically require
>using <> - e.g. MDNs and responses from mail robots, neither of
>which are constrained to exactly one recipient.

OTOH: There is no requirement that the generator of these responses 
(when presented with a request/need to sent such a message to more 
than one recipient) create a single copy of the message as opposed to 
one personally addressed copy per recipient. Creating multiple copies 
preserves the "Only One Recipient for a 'Mail From <>' message" rule.

From: "Hector Santos" <[email-masked]>
To: "John C Klensin" <[email-masked]>, <[email-masked]>
Subject: Re: A request and a warning (was: Re: Bounce/System Notification Address Verification)
Date: Tue, 28 Jun 2005 00:35:01 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

----- Original Message -----
From: "John C Klensin" <[email-masked]>

> Folks,
>
> I've been quietly watching this thread and a few others.  I'd
> like to encourage people to stop, not only the aspects of this
> that are pretty close to name-calling, but the whole discussion
> for a bit and take things up one abstraction level.

Its all good here. I'm ready to smoke the proverbial peace pipe.

> Let's suppose that a first cut at 2821bis were actually about to
> appear.

ok. May I ask what is a "bis" ?  Not familar with that term.

> From the perspective of the standard, all of these discussions
> about tricky address verifications, sender-receiver command
> relationships, and so on, are not about conformance.  Instead,
> they are about whether it is a good or bad idea to violate the
> standard in various ways for operational purposes.

I'm not sure if I follow this line of thought but no doubt I want to know
more.

I should also note that I am not bent of a CBV, but I am not that never
waited on the IETF for a solution to the "email problem."   To me, the
Return Path is something that is fundamental to the process, and unlike
HELO,  it is indeed a candidate for validation, simply because it is a
required item for a normal part of the mail flow - the bounce.

So based on this important framework, the CBV is a very viable idea, not
necessarily as a SMTP based call back, but as a proof of concept.

So in that vain, if I understood your statement, I don't see it is a
violiation to perform a "return path validation" concept.  To me, the
different between a CBV and a normal delay bounce action is *time*.    A
bounce is basically a "time shifted concept" of return path validation
during the process of performing the bounce.

> At the risk of causing shock all over the email community, I
> expect to have draft-klensin-rfc2821bis-00 posted late this week
> or, at worst, early next week.

Shock? You are understanding it. EARTHQUAKE! <g>

Wonderful.  I volunteer any services I can offer.

> There is a small, ad hoc, evaluation committee looking at those
> groups of changes with the intent of providing some evaluations
> for the list to look at: the decisions as to which marginal
> clarifications are worth making are not going to be made by the
> contributor and myself alone.

I don't pretend to be an expert of the IETF process, there is no better time
than now to begin a new revamp period. It would the second time in our
history and its abound time.  The last time around the industry converge on
a standard.  This time the industry will converge to sholve the major
security issues with the email framework. Anything short of an emphasis on
technical legal compliant enforcement or the migration towards technical
legal compliant enforcement will fall short of the goals.  Keep in mind, I
am not implying a break down, but instead I think it can down with major
backward compliancy in mind.

> In addition to all of the little details, there are a few
> strategic issues that will need to be addressed.  They include:
>
> (i) The style and tone with regard to operational or security
> (including spam-fighting) issues as outlined above.  It is my
> personal belief that there is ample room for a "best practices
> in mail system configuration to resist spam" document, but its
> content does not belong as part of the transport spec.

I agree.  Fighting the spam problem would be a natural benefits of a
stronger SMTP TMS (Transaction Management and Security) specification.

> So my proposal is to leave the present structure of 2821 unchanged.  I
> would note that, if we start considering major changes in
> restrictions and directions about them, the odds of going down
> ratholes are very high and the odds of needing to recycle at
> Proposed are probably even higher.

> (ii) RFC 3552 contains, as an example, what is essentially a
> rewritten Security Considerations section for 2821.  My personal
> belief is that sample section is sufficiently unrealistic with
> regard to operational Internet mail systems that a system that
> followed all of the recommendations of that text would be quite
> secure because it would not be able to communicate with anyone
> else and no one would communicate with it.   I've started to
> raise that issue with the IAB (from whence the RFC originated) a
> couple of times, but have always gotten sidetracked.  While
> there is some new material in the Security Considerations
> section of 2821bis, the additional recommendations of 3552 have
> essentially been ignored.  People should start thinking about
> that situation and what you/we want to do about it:  I believe
> that, if the IESG insists on replacing that section with one
> that is 3552-conformant, it will be impossible to get an
> informed consensus for moving 3821bis forward.

Let me see if I got this right, we should look at 3552 as a framework if we
want a better chance at adoption, but you are afraid that we might be able
to get a concensus of all the considerations in the document?

> (iii) 2821bis is rather thoroughly intertwined with 2822bis.  At
> a minimum, it is clear that neither one can go to Draft without
> the other, at least until the procedures of RFC 3967 are
> invoked.   We need to think through the implications and
> relationships between these two documents and how they should be
> processed.
>
> (iv) More generally, we need to figure out, somehow, whether it
> is possible to progress this document without reactivating DRUMS
> or the equivalent and make a recommendation to the ADs on that
> matter.  I fear that everyone who is critical-path for this is
> too busy to make opening the WG a good idea.  On the other hand,
> without the structure of a WG, it will take a good deal of
> self-discipline on all of our parts to avoid the long message
> threads about irrelevant or unimportant issues that could make
> getting consensus on a revised document (or pair of documents)
> largely impossible.

It is possible to have multiple workings groups, to split the issues (and
also lower the thread fibers)?  This is just off rough breakdown:

 - 3821-BCM

   Backward Compatibilty (legacy), Migration Considerations

 - 3821-TMS

  Transaction Management and Security (state machine/ESMTP)

 - 3821-PAYLOAD

   3822 Considerations

 - 3831-SPAM

   Integration with new email proposals such as SPF, SENDERID/PRA,
   CSV, DKIM, BATV, SRS, including MFA (Mail Filter Agent) considerations
   such as Seive, etc.

This way we get the various experts delegated with concentrated focused
efforts and you can probably extract what is gain and purge want is not
necessary to produce your documents.   The goal is not to break the system,
but to take what we learned over the last 20+ years and consolidate may of
the ideas already in place, clean up the ambiguity, and begin to offer a
strong optional enforcable system that is design with maximum backward
compatibility and migration in mind.

I'm excited!!  I understand that this may be too much, but its better to
look at the total scope and limit it from there, if need be.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

Date: Tue, 28 Jun 2005 00:07:10 -0400
From: Keith Moore <[email-masked]>
To: John C Klensin <[email-masked]>
Cc: [email-masked]
Subject: Re: A request and a warning
Sender: [email-masked]

> (i) The style and tone with regard to operational or security
> (including spam-fighting) issues as outlined above.  It is my
> personal belief that there is ample room for a "best practices
> in mail system configuration to resist spam" document, but its
> content does not belong as part of the transport spec.  So my
> proposal is to leave the present structure of 2821 unchanged.  I
> would note that, if we start considering major changes in
> restrictions and directions about them, the odds of going down
> ratholes are very high and the odds of needing to recycle at
> Proposed are probably even higher.

I agree that this is the right way to go, and concur with your assertion 
about rathole potential.  I'd also assert that operational practices may 
need to change more frequently than protocol specifications, so having 
them in separate documents that can be revised independently of one 
another makes sense from this perspective also.

Keith

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: A request and a warning
Date:  Tue, 28 Jun 2005 05:53:50 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 36
Sender: [email-masked]

John C Klensin wrote:

> I expect to have draft-klensin-rfc2821bis-00 posted
> late this week or, at worst, early next week.

This will be very interesting.  At about 4100 enough
time before 4821.

> 2821bis is rather thoroughly intertwined with 2822bis.

There's no such thing as an 2822bis, and except from some
oddities with NO-WS-CTL and <msg-id> 2822 is fine.

That hurts 2821 in the case of <General-Address-Literal>,
and I hope you'll replace this construct by <IPvFuture>
found in STD 66.  While you're at it grab also the other
address literals from STD 66, they are simply better.

> neither one can go to Draft without the other

2822 is near to Draft, 2821bis better starts as Proposed.

> Thoughts welcome, either before or after the I-D goes up.

Let's add the trailing dot for `host ai`.

Let's get rid of the "IPv6:" tag.

Let's make the two orthogonal MAIL FROM concepts clear.

Let's get rid of the "source route" explanation, it's a
mess of MUST accept / SHOULD ignore / MAY respect.  Only
MUST accept and ignore, nothing else.

                        Bye, Frank

Date: Mon, 27 Jun 2005 22:21:04 -0400
From: John C Klensin <[email-masked]>
To: [email-masked]
Subject: A request and a warning (was: Re: Bounce/System Notification Address Verification)
Sender: [email-masked]

Folks,

I've been quietly watching this thread and a few others.  I'd
like to encourage people to stop, not only the aspects of this
that are pretty close to name-calling, but the whole discussion
for a bit and take things up one abstraction level.

Let's suppose that a first cut at 2821bis were actually about to
appear.   The existing 2821 takes a pretty hard line on
approaches like "well, if the return-path looks like X, then it
is plausible to impose restrictions A, B, or C on the number of
recipients".  Basically, unless you invoke the loophole, the
minimum number of RCPT commands to be accepted is 100, and any
implementation that cannot do so is non-conformant.  Of course,
there is the loophole, and the loophole permits almost anything
plausible to be enabled, at configuration time, in the name of
security generally and repelling attacks in particular.  

>From the perspective of the standard, all of these discussions
about tricky address verifications, sender-receiver command
relationships, and so on, are not about conformance.  Instead,
they are about whether it is a good or bad idea to violate the
standard in various ways for operational purposes.

At the risk of causing shock all over the email community, I
expect to have draft-klensin-rfc2821bis-00 posted late this week
or, at worst, early next week.   Tony Hansen has done a
superhuman job of converting the format in which the document
has been maintained and worked on for the last four years into
an XML2RFC format that can be used to generate I-Ds in an
acceptable form.  Unless I slipped up, the -00 draft reflects
all of the clear errors and substantive corrections identified
in the last four years.  It does not reflect a number of
proposed "this will make it more clear but does not change the
definition" changes, especially when those changes, in my
opinion, are just confusing in a different way.

There is a small, ad hoc, evaluation committee looking at those
groups of changes with the intent of providing some evaluations
for the list to look at: the decisions as to which marginal
clarifications are worth making are not going to be made by the
contributor and myself alone.

In addition to all of the little details, there are a few
strategic issues that will need to be addressed.  They include:

(i) The style and tone with regard to operational or security
(including spam-fighting) issues as outlined above.  It is my
personal belief that there is ample room for a "best practices
in mail system configuration to resist spam" document, but its
content does not belong as part of the transport spec.  So my
proposal is to leave the present structure of 2821 unchanged.  I
would note that, if we start considering major changes in
restrictions and directions about them, the odds of going down
ratholes are very high and the odds of needing to recycle at
Proposed are probably even higher.

(ii) RFC 3552 contains, as an example, what is essentially a
rewritten Security Considerations section for 2821.  My personal
belief is that sample section is sufficiently unrealistic with
regard to operational Internet mail systems that a system that
followed all of the recommendations of that text would be quite
secure because it would not be able to communicate with anyone
else and no one would communicate with it.   I've started to
raise that issue with the IAB (from whence the RFC originated) a
couple of times, but have always gotten sidetracked.  While
there is some new material in the Security Considerations
section of 2821bis, the additional recommendations of 3552 have
essentially been ignored.  People should start thinking about
that situation and what you/we want to do about it:  I believe
that, if the IESG insists on replacing that section with one
that is 3552-conformant, it will be impossible to get an
informed consensus for moving 3821bis forward.

(iii) 2821bis is rather thoroughly intertwined with 2822bis.  At
a minimum, it is clear that neither one can go to Draft without
the other, at least until the procedures of RFC 3967 are
invoked.   We need to think through the implications and
relationships between these two documents and how they should be
processed.

(iv) More generally, we need to figure out, somehow, whether it
is possible to progress this document without reactivating DRUMS
or the equivalent and make a recommendation to the ADs on that
matter.  I fear that everyone who is critical-path for this is
too busy to make opening the WG a good idea.  On the other hand,
without the structure of a WG, it will take a good deal of
self-discipline on all of our parts to avoid the long message
threads about irrelevant or unimportant issues that could make
getting consensus on a revised document (or pair of documents)
largely impossible.

Thoughts welcome, either before or after the I-D goes up.

     john

From: "Hector Santos" <[email-masked]>
To: <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification
Date: Mon, 27 Jun 2005 21:10:38 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

----- Original Message -----
From: "Keith Moore" <[email-masked]>
To: "Hector Santos" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Monday, June 27, 2005 4:34 PM
Subject: Re: Bounce/System Notification Address Verification

> There is also no reason that a server should refuse multiple RCPT TOs
> when given a return path of <>.

I believe there is. The majority of good systems do not behave this way,
especially when issueing a RANDOM address which is what this thread is
about.

> Wrong.  There is no prohibition that I'm aware of against using <> for
> other purposes, and there are some standards that specifically require
> using <> - e.g. MDNs and responses from mail robots, neither of
> which are constrained to exactly one recipient.

Keith, we were referring (atleast I was) to the fact that they do EXIST 1
RCPT limits for a NULL return path.  There are plenty of systems that work
in this mode whether you care to believe that or not.  The conflict you seem
to forget is that your multi rcpt-to/null return path allowance is a source
of spam.

> MAIL FROM:<postmaster@domain> means "send bounces to
> postmaster@domain", NOT "no bounce needed".

In regards to a CBV,  a postmaster@domain is skipped. No bounce address
validation is required.  However, this is optional in our implementation
since the domain may be invalid.

> > Why should the rest of the compliant world be bothered by a broken list
> > server mail agent?
>
> It's not clear what is broken in this case.

In my view, the agent that issues a non-null return path with the
expectation of no bounce activity should occur is broken.

> But in general, lots of
> mail software authors and/or operators are making dubious assumptions
> about what kinds of spam countermeasures are reasonable, and those
> assumptions conflict with one another far too often.

You need to separate 2821 from 2822 (body) Keith if you want to see the
light at the end of the tunnel.  I am going to concentrate on SMTP level
considerations only.  The rest is subjective out of scope administrative
local policy rules and yes, if you try to blend it into the 2821 automated
technical process, you wil have conflicts.

> well, it appears that your mail server rejects a lot of perfectly valid
> mail for other reasons known only to you, so I guess I'm not surprised.

I wish you would stop your own going pot shots at me. It is non-productive,
antagonistic, insulting and quite frankly very tiresome.  I really hate to
point it out,  but the only real appearance you experience on our server is
your own twit block entry in our black list.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

From: "Hector Santos" <[email-masked]>
To: <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification
Date: Mon, 27 Jun 2005 20:38:13 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

----- Original Message -----
From: "Ned Freed" <[email-masked]>

> > Wrong.  There is no prohibition that I'm aware of against using <> for
> > other purposes, and there are some standards that specifically require
> > using <> - e.g. MDNs and responses from mail robots, neither of
> > which are constrained to exactly one recipient.
>
> FWIW, Keith is correct about this and I found this out the hard way.

Hi Ned,

I never said it was not.  I just agreed with Valdis in that there do exist
one limit behaviors.

We didn't imply it was not possible and I had already stated it was possible
for a system to operate in a post smtp recipient validation mode.

The fact is that they do exist (NULL return path, 1 RCPT TO) and our CBV
engineering covers it with an RSET option:

    UseRSET              True               ; Solves 1 RCPT limit for MAIL
FROM: <>

On an open ended basis the payoff is high to trap for such open-relay
operations.

> [example valid story]

If you have a relationship or social/busines network, then I don't believe a
CBV should be done.  Like in your case, you had a special relationship.

The issue is Return Path Validation.

Standard/BCP operations: MAIL FROM:

1.  <>  --> no bounce needed
2.  <other address>  --> bounce possible. Address must be valid.

For the Return Path Validator (CBV) implementation:

3.  <>  --> skip CBV
4.  <postmaster @ domain>  --> skip CBV
5.  <other address>  -->  CBV possible. Address must be valid.

The CBV skips 3 for obvious reasons.  In our implementation 4 is skipped by
default:

    SkipPostMaster       True        ; If mail from postmaster, skip CBV

Now, at the remote site, for our CBV implementation, the optional open relay
test is done with a random address. If it is accepted, it is rejected.

    OpenRelayCheck       True
    RejectOpenRelay      True
    ResponseCodeRelay  552         ; Site is an open relay

Two years of implementation across thousands of systems, no complaints or
reports that has not been addressed.

Verizon.Net is a big ISP and they perform a CBV on every incoming
unauthorized transactions. But it does it immediately at MAIL FROM.  We wait
until RCPT TO is determined to reduce the overhead CBV need

Check out how Verizon.Net does using its MailPass server.

Here I telnet to verizon.net and I am going to have it verify my (good)
address:

220 sv19pub.verizon.net MailPass SMTP server v1.2.0 -
        013105113116JY+PrW ready Mon, 27 Jun 2005 18:01:13 -0500
helo hdev1
mail from: <[email-masked]>
[1 second delay]
250 Sender <[email-masked]> OK
quit
221 sv19pub.verizon.net closing connection

and here was the verizon.net CBV session captured on my end:

19:03:28 C: HELO sv19pub.verizon.net
19:03:28 S: 250 winserver.com, Pleased to meet you.
19:03:28 C: MAIL FROM:<>
19:03:28 S: 250 <>... Sender ok.
19:03:28 C: RCPT TO:<[email-masked]>
19:03:28 ** WCX Process: wcsap  ret: -1
19:03:28 S: 250 <[email-masked]>... Recipient ok
19:03:28 C: QUIT
19:03:28 S: 221 closing connection

and here is another session where it fails a bad user:

220 sv9pub.verizon.net MailPass SMTP server v1.2.0 -
        013105113116JY+PrW ready Mon, 27 Jun 2005 18:34:34 -0500
helo hdev1
250 sv9pub.verizon.net
mail from: <[email-masked]>
[1-2 seconds delay]
550 You are not allowed to send mail:sv9pub.verizon.net

and the CBV session on my end:

19:36:18 C: HELO sv9pub.verizon.net
19:36:18 S: 250 winserver.com, Pleased to meet you.
19:36:18 C: MAIL FROM:<>
19:36:18 S: 250 <>... Sender ok.
19:36:18 C: RCPT TO:<[email-masked]>
19:36:18 S: 550 User not a member of domain: <[email-masked]>
19:36:18 C: RSET
19:36:18 S: 250 Reset State
19:36:18 C: MAIL FROM:<[email-masked]>
19:36:18 S: 250 <[email-masked]>... Sender validation
pending. Continue.
19:36:18 C: RCPT TO:<[email-masked]>
19:36:18 S: 550 User not a member of domain: <[email-masked]>

Check out what VERIZON.NET is doing here in the CBV for a failed address.

If it is rejected, it issues a RSET and tries again with non-NULL MAIL FROM.

Useless on our system but I think if I remember, yahoo or hotmail, or some
other big site didn't like validating a user for a NULL return path.

Anyway, I think a open relay test has a payoff.  Exceptions can be
whitelisted.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

From: [email-masked]
Cc: Hector Santos <[email-masked]>, [email-masked], [email-masked], [email-masked]
To: Keith Moore <[email-masked]>
Date: Mon, 27 Jun 2005 15:25:43 -0700 (PDT)
Subject: Re: Bounce/System Notification Address Verification
Sender: [email-masked]

> > > In general, since the message that's sent with the null
> > > MAIL FROM generates the RCPT TO from the
> > > inbound MAIL FROM, and there's only one of those, then
> > > you can only get one outbound RCPT TO.
> >
> > Right.

> Wrong.  There is no prohibition that I'm aware of against using <> for
> other purposes, and there are some standards that specifically require
> using <> - e.g. MDNs and responses from mail robots, neither of
> which are constrained to exactly one recipient.

FWIW, Keith is correct about this and I found this out the hard way. We had a
customer that absolutely insisted on setting things up to bounce mail with an
empty MAIL FROM and multiple RCPT TOs. There are several ways to do this with
our software and I was experimenting at home trying to find the best one.
Unfortunately, after I finished my experiment and replied to the customer I
forgot to tear all the stuff out of my own configuration. Some time later
I stumbled over it. Of course I removed it but then I got curious and started
looking at my logs. Seems it rejected several messages which, given the
source, pretty much had to be legitimate. Additional followup showed that
at least two of these were valid emails that should have been delivered. The
others were probably MDNs.

Now, there was no reason for these particular valid emails to have had MAIL
FROM:<>, but as Keith says, nothing forbids it either, and it is at present the
only way to say "I don't want any automatic responses to this, thank you very
much".

				Ned

Date: Mon, 27 Jun 2005 16:34:00 -0400
From: Keith Moore <[email-masked]>
To: "Hector Santos" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Bounce/System Notification Address Verification
Sender: [email-masked]

> >> What is the BCP for allowing multiple RCPT TO
> >> when the return path is NULL?

It is not appropriate for a server to assume that MAIL FROM:<> is an
indication of a bounce message.  There are valid reasons to use <>
with other than bounced mail.   For instance, an MDN can be sent to
multiple parties if the originator of the subject message requests it
and the recipient explicitly consents to do so, and such an MDN should
still have a return-path of <>.

There is also no reason that a server should refuse multiple RCPT TOs
when given a return path of <>.  Of course, a server is free to refuse
a RCPT TO with a 452 error code (too many recipients) if it's not
willing to accept more than one RCPT address.  But either returning a
5xx error code with a valid recipient address, or returning a 2xx error
code and silently failing to deliver mail to that recipient, are
contrary to the  standards and will break things.

> > In general, since the message that's sent with the null
> > MAIL FROM generates the RCPT TO from the
> > inbound MAIL FROM, and there's only one of those, then
> > you can only get one outbound RCPT TO.
> 
> Right.

Wrong.  There is no prohibition that I'm aware of against using <> for
other purposes, and there are some standards that specifically require
using <> - e.g. MDNs and responses from mail robots, neither of
which are constrained to exactly one recipient.

>  It could be, however, as Keith suggest, be operating in post smtp
> mode. 

I don't know what "post smtp mode" is, or what you think I suggested.

> I mean it, there are two options for "no bounce needed" requests:
> 
>         Mail from: <> or <postmaster[@domain]>
> 
> Right?

no.  MAIL FROM:<> is the recommended way to say "no bounce needed".
For MTAs that support the DSN extension, you can also say NOTIFY=NEVER,
but that's not as widely supported and it only applies to DSNs (not to
other kinds of notifications like MDNs or messages from mail robots).
There are no other standard ways to do that that I'm aware of .
MAIL FROM:<postmaster@domain> means "send bounces to
postmaster@domain", NOT "no bounce needed".

> Why should the rest of the compliant world be bothered by a broken list
> server mail agent?

It's not clear what is broken in this case.  But in general, lots of
mail software authors and/or operators are making dubious assumptions
about what kinds of spam countermeasures are reasonable, and those
assumptions conflict with one another far too often.  It's not
reasonable to assume that a message with an invalid MAIL FROM address
is spam.  Nor is it reasonable for a server to assume that a message
with MAIL FROM:<> can only have one recipient.  I'm not aware of
anything in the standards that says it's safe to make these assumptins.

> I have on my personal setup as a filtering rule:
> 
>     Reject if MailFrom "<>"  and TotalRcpt > 1

well, it appears that your mail server rejects a lot of perfectly valid
mail for other reasons known only to you, so I guess I'm not surprised.

Keith

From: "Hector Santos" <[email-masked]>
To: <[email-masked]>
Cc: "IETF-SMTP" <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification 
Date: Mon, 27 Jun 2005 15:16:09 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

From: <[email-masked]>

>> What is the BCP for allowing multiple RCPT TO
>> when the return path is NULL?

> In general, since the message that's sent with the null
> MAIL FROM generates the RCPT TO from the
> inbound MAIL FROM, and there's only one of those, then
> you can only get one outbound RCPT TO.

Right.   So you wouldn't normally expect a second address to be accepted,
which adds weight to the a "random" address "open relay" test from a NULL
PATH.    It could be, however, as Keith suggest, be operating in post smtp
mode.  Our experience is, that this is a rare situation "today" because of
increase awareness.  But when it does happen, it it either good or bad, and
the good is white listed to skip the CBV test.   Bad systems don't complain
<g>

> The problem of course, is that sometimes, things generate
> bounces or pseudo-bounces from something other than the
> inbound MAIL FROM (for instance, LSoft's Listserv sends a
> lot of things that aren't technically DSNs, but *should* be
> treated  as "drop rather than bounce" - for example, the
> automated cookies for subscription confirmation, etc.  If they
> get routed to an invalid mailbox, we want them to be dropped
> on the floor, as the cookie will be expired via other means
> anyhow..

Ok, but how does this change the system wide requirements and definition of
RFC 2821 Return Path and system flow expectations?

Shouldn't the listserver cookie agent use a NULL or "PostMaster" address per
specification if it does not desire to be burden with post-smtp initiated
bounces at the cookie receiver host?

I mean it, there are two options for "no bounce needed" requests:

        Mail from: <> or <postmaster[@domain]>

Right?

Why should the rest of the compliant world be bothered by a broken list
server mail agent?

Of course,  the problem is only exhibited if the receiver is performing post
smtp validation which already says he is operating in a vulnerable mode
anyway.

And I would venture to guess that your experience with the LSoft's Listserv
cookie agent is modeled on a RCPT based validation concept where it will
operate ideally.  I don't know, but it should expect not to receive bounces
if it uses a non-null or non-postmaster return path.  Right?

>> Don't most system use accept one recipient for a null return path?

> I believe that most systems don't actually *verify* it has exactly one
> RCPT TO, unless it's an aftermarket add-on.

Right,  I've seen different results on different servers.

I have on my personal setup as a filtering rule:

    Reject if MailFrom "<>"  and TotalRcpt > 1

but it is not built-in.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

To: Hector Santos <[email-masked]>
Cc: IETF-SMTP <[email-masked]>
Subject: Re: Bounce/System Notification Address Verification 
From: [email-masked]
Date: Mon, 27 Jun 2005 13:40:03 -0400
Sender: [email-masked]

--==_Exmh_1119894002_6336P
Content-Type: text/plain; charset=us-ascii

On Mon, 27 Jun 2005 12:38:42 EDT, Hector Santos said:

> What is the BCP for allowing multiple RCPT TO when the return path is NULL?

In general, since the message that's sent with the null MAIL FROM generates
the RCPT TO from the inbound MAIL FROM, and there's only one of those, then
you can only get one outbound RCPT TO.

The problem of course, is that sometimes, things generate bounces or pseudo-bounces
from something other than the inbound MAIL FROM (for instance, LSoft's Listserv
sends a lot of things that aren't technically DSNs, but *should* be treated
as "drop rather than bounce" - for example, the automated cookies for
subscription confirmation, etc.  If they get routed to an invalid mailbox, we
want them to be dropped on the floor, as the cookie will be expired via other
means anyhow..

> Don't most system use accept one recipient for a null return path?

I believe that most systems don't actually *verify* it has exactly one
RCPT TO, unless it's an aftermarket add-on.

--==_Exmh_1119894002_6336P
Content-Type: application/pgp-signature

--==_Exmh_1119894002_6336P--

To: Hector Santos <[email-masked]>
Cc: IETF-SMTP <[email-masked]>
Subject: Re: Re Anonymous Final Destination and mail submission 
From: [email-masked]
Date: Mon, 27 Jun 2005 13:33:28 -0400
Sender: [email-masked]

--==_Exmh_1119893607_6336P
Content-Type: text/plain; charset=us-ascii

On Mon, 27 Jun 2005 08:46:11 EDT, Hector Santos said:

> I don't think you can blame a "black box" return path validator, CBV or
> otherwise, if the remote host is not compliant with RFC 2821 null-path
> requirements.  If the host was a dedicated list server, the above should
> serve as a good indication to kill or deactivate the list member address as
> a bad address.

The problem is that they keep trying to post to the list even though they're
not subscribed (as spammers are wont to do), and what goes kaboing is when
we try to send them the "piss off, you're not a subscriber" bounce.

--==_Exmh_1119893607_6336P
Content-Type: application/pgp-signature

--==_Exmh_1119893607_6336P--

From: "Hector Santos" <[email-masked]>
To: "IETF-SMTP" <[email-masked]>
Subject: Bounce/System Notification Address Verification
Date: Mon, 27 Jun 2005 12:38:42 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

From: "Keith Moore"

> > which allows you test for zombie/open relay.  Maybe the host
> > will say yes to> everything.
>
> if the server says yes to everything, it doesn't mean it's a zombie or
> open relay, nor does it mean that the address is bogus.  It just means
> that the server isn't doing checking at RCPT TO time.  nothing in the
> standards requires it to do so.

Very true.  The system can be operating in post SMTP mode which to me, means
the system is probably already abused with bounce-based attacks and/or
over-burden with bounce requirements if its operating in a standard expected
SMTP mode and not just dumping non-deliverable mail.

Question:

What is the BCP for allowing multiple RCPT TO when the return path is NULL?

Don't most system use accept one recipient for a null return path?

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

Date: Mon, 27 Jun 2005 09:26:15 -0400
From: Keith Moore <[email-masked]>
To: Hector Santos <[email-masked]>
Cc: IETF-SMTP <[email-masked]>
Subject: Re: Re Anonymous Final Destination  and mail submission
Sender: [email-masked]

>>Well, you can do HELO/MAIL FROM:<>/RCPT TO:<address>/RSET,
> 
> 
> Its better to do:
> 
> HELO/MAIL FROM:<>/RCPT TO:<address>/RCPT TO: <random>/RSET
> 
> which allows you test for zombie/open relay.  Maybe the host will say yes to
> everything.

if the server says yes to everything, it doesn't mean it's a zombie or 
open relay, nor does it mean that the address is bogus.  It just means 
that the server isn't doing checking at RCPT TO time.  nothing in the 
standards requires it to do so.

>>though in my experience some servers will reject a RCPT TO (regardless of the
>>address) if the MAIL FROM address was empty.
> 
> 
> This has not been our product implementation experience in nearly 2 years in
> the hands of customers world wide.

your reality is apparently different than mine :)

>>Yes, this means that the bounce would never be delivered, but it _doesn't_ 
>>mean the email is invalid.
> 
> then the server is non-compliant  RFC 2821, and a rejection is justified.

some of us realize that even if a mail domain has misconfigured its MTA 
to reject MAIL FROM:<> the message might still contain content that the 
recipient needs to see.  a misconfigured MTA is not a reliable indicator 
of spam.

> The payoff is high given that over 60-80% of the time, the test is correct.
> Any false positives, if any, will be quickly resolved.  The good news is
> that good systems are RFC 2821 compliant.  Bad systems are not.

unfortunately there are a lot of ill-conceived anti-spam measures 
deployed out there.  well-intentioned people do technically stupid 
things like configure their mailers to reject any RCPT command that 
follows MAIL FROM:<>.  then other well-intentioned people decide that 
they're going to reject any mail which has a MAIL FROM address for which 
the inbound MX server works this way.  I have somewhat more sympathy 
with the latter tactic than the former, but neither tactic is 
recommended by the standards, and the combination of ill-conceived 
tactics makes mail a lot less reliable.

we really need a uniform set of recommendations for things like this.

> 
> Keith, lets look at the other side.
> 
> A system issues a return path that you do not check. You also do not perform
> a recipient validation at the SMTP 2821 level and perform the recipient
> check at the gateway processor.  A bounce is determined to be required.
> 
> The burden is now on your system to deliver the bound over a specified
> period. It fails eventual.
> 
> Multiple that with 60-80% of your transactions being in this state and you
> now know why the SORBIG-based generation eVirus exist. 

viruses would exist even if these checks were made.  the fact that the 
Internet mail system does not require MTAs to check the validity of 
addresses immediately (allowing them to bounce messages later) is 
independent of the conditions that allow viruses to exist.  checking the 
validity of such things may reduce the load on your mail system 
significantly (and it's generally something that I recommend), but it 
won't do much in the long run to reduce virus propagation.  (it might 
even help viruses propagate faster because your mail system will be 
running more efficiently)

Keith

From: "Hector Santos" <[email-masked]>
To: <[email-masked]>
Cc: "IETF-SMTP" <[email-masked]>
Subject: Re: Re Anonymous Final Destination and mail submission 
Date: Mon, 27 Jun 2005 08:46:11 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

From: <[email-masked]>

> Anywhere from 2 to 10 percent of all mail that makes it into
> our Listserv server and then bounces (usually due to a
> long-gone listname on some spammer's list)
> is then rejected by the purported site:

>  553 You are not authorized to send mail as <>

> 126.com seems to be particularly flagrant at it. I need to
> check why I'm even accepting mail from them at all.

Ok, find out and let us know <g>

I don't think you can blame a "black box" return path validator, CBV or
otherwise, if the remote host is not compliant with RFC 2821 null-path
requirements.  If the host was a dedicated list server, the above should
serve as a good indication to kill or deactivate the list member address as
a bad address.

> Hint - if it wasn't common, would www.rfc-ignorant.org have
> a 'dsn' zone? ;)

I guess every social network has its kinks :-)

Anyway,  I'm hungry... Breakfast time. :-)

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

To: Hector Santos <[email-masked]>
Cc: IETF-SMTP <[email-masked]>
Subject: Re: Re Anonymous Final Destination and mail submission 
From: [email-masked]
Date: Mon, 27 Jun 2005 01:21:22 -0400
Sender: [email-masked]

--==_Exmh_1119849682_3633P
Content-Type: text/plain; charset=us-ascii

On Sun, 26 Jun 2005 22:22:06 EDT, Hector Santos said:

> Its better to do:
> 
> HELO/MAIL FROM:<>/RCPT TO:<address>/RCPT TO: <random>/RSET

Woe unto the site where 'random' actually exists. ;)

> > though in my experience some servers will reject a RCPT TO (regardless of
> the
> > address) if the MAIL FROM address was empty.
> 
> This has not been our product implementation experience in nearly 2 years in
> the hands of customers world wide.  Thats not to say it has not happen but
> to say.....

Anywhere from 2 to 10 percent of all mail that makes it into our Listserv server
and then bounces (usually due to a long-gone listname on some spammer's list)
is then rejected by the purported site:

<<< 553 You are not authorized to send mail as <>

126.com seems to be particularly flagrant at it. I need to check why I'm even
accepting mail from them at all.

Hint - if it wasn't common, would www.rfc-ignorant.org have a 'dsn' zone? ;)

--==_Exmh_1119849682_3633P
Content-Type: application/pgp-signature

--==_Exmh_1119849682_3633P--

From: "Hector Santos" <[email-masked]>
To: "IETF-SMTP" <[email-masked]>
Subject: Re: Re Anonymous Final Destination  and mail submission
Date: Sun, 26 Jun 2005 22:22:06 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

----- Original Message -----
From: "Keith Moore" <[email-masked]>
To: "Robert A. Rosenberg" <[email-masked]>
Cc: "IETF-SMTP" <[email-masked]>
Sent: Sunday, June 26, 2005 7:05 PM
Subject: Re: Re Anonymous Final Destination and mail submission

>
>  > Obviously if the domain does not exist (ie: There is no
> > MX or A record) attempting to send a bounce is an exercise in futility.
> > Checking for the actual existence of that address (ie: That there is a
> > mailbox that can accept the bounce message) requires the issuing of a
> > VEFY Command which many/most SMTP Servers will not respond to for
> > security/privacy reasons.
>
> Well, you can do HELO/MAIL FROM:<>/RCPT TO:<address>/RSET,

Its better to do:

HELO/MAIL FROM:<>/RCPT TO:<address>/RCPT TO: <random>/RSET

which allows you test for zombie/open relay.  Maybe the host will say yes to
everything.

> though in my experience some servers will reject a RCPT TO (regardless of
the
> address) if the MAIL FROM address was empty.

This has not been our product implementation experience in nearly 2 years in
the hands of customers world wide.  Thats not to say it has not happen but
to say.....

> Yes, this means that the
> bounce would never be delivered, but it _doesn't_ mean the email is
invalid.

then the server is non-compliant  RFC 2821, and a rejection is justified.

The payoff is high given that over 60-80% of the time, the test is correct.
Any false positives, if any, will be quickly resolved.  The good news is
that good systems are RFC 2821 compliant.  Bad systems are not.

Keith, lets look at the other side.

A system issues a return path that you do not check. You also do not perform
a recipient validation at the SMTP 2821 level and perform the recipient
check at the
gateway processor.  A bounce is determined to be required.

The burden is now on your system to deliver the bound over a specified
period. It fails eventual.

Multiple that with 60-80% of your transactions being in this state and you
now know why the SORBIG-based generation eVirus exist.   It is based on the
three exploitable ideas or behaviors in your traditional SMTP setup:

1) No verification required for MAIL FROM

2) No authorization required for final destination

2) A legacy of "old school" systems still behaving as if they are in UUCP
mode where a gateway or router determines local vs. remote user.  Many
systems that do offer SMTP level RCPT validation, do not turn on it for
three reasons:

2.a)  They don't know about it or they are still use to the gateway concept.

2.b)  Scalability - large inbound traffic, too slow rcpt verification.

2.c)  Have a MFA (mail filter agent) working in post smtp mode.

Every now or then, we still need to inform sysops about turning on their
SMTP level local user validation to reduce their bounce loads, especially in
the SORBIG era. "Man, I am getting killed with bounces. How can we reduce
it?"

Modern high-end high efficient multi-threaded IOCP based servers with today
fast machines can handle scalability pretty efficiently these days.
Database I/O is pretty fast these days.  Even AOL - the so called largest
ISP, switched form post smtp validation to dynamic smtp validation.
Obviously there are many more smaller systems than large ones, so they can
support doing dynamic smtp checks without penalty.

I don't know how many systems activate a MFA at the DATA stage, but that is
how we do it on our system (by default).   Mail Content based rejections (an
administrative defined policy) at the DATA state helps reduce bounce
requirements.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

Date: Sun, 26 Jun 2005 19:05:21 -0400
From: Keith Moore <[email-masked]>
To: "Robert A. Rosenberg" <[email-masked]>
Cc: IETF-SMTP <[email-masked]>
Subject: Re: Re Anonymous Final Destination  and mail submission
Sender: [email-masked]

 > Obviously if the domain does not exist (ie: There is no
> MX or A record) attempting to send a bounce is an exercise in futility. 
> Checking for the actual existence of that address (ie: That there is a 
> mailbox that can accept the bounce message) requires the issuing of a 
> VEFY Command which many/most SMTP Servers will not respond to for 
> security/privacy reasons.

Well, you can do HELO/MAIL FROM:<>/RCPT TO:<address>/RSET, though in my 
experience some servers will reject a RCPT TO (regardless of the 
address) if the MAIL FROM address was empty.  Yes, this means that the 
bounce would never be delivered, but it _doesn't_ mean the email is invalid.

> Your statement that you should be "checking the DNS name of the MAIL 
> FROM _before_ you agree to relay mail to a recipient" applies to the MSA 
> not when (as I qualified my statement) acting as a "final destination" 
> MTA Server since at that point you are not relaying but attempting to do 
> delivery.

Perhaps unfortunately, there are often many more hops than just 
submission and delivery. Of course if you know than an upstream MTA has 
already done the checks you can avoid doing them again, but in general 
you don't know that. Ideally you should have as few MTAs as possible in 
the signal path, and errors should be detected as early as possible.
I haven't tried doing any actual measurement, but my impression is that 
an increasing number of large email networks are figuring this out.

Keith

Date: Sun, 26 Jun 2005 16:00:57 -0400
To: IETF-SMTP <[email-masked]>
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: Re Anonymous Final Destination  and mail submission
Sender: [email-masked]

At 11:31 -0400 on 06/26/2005, Keith Moore wrote about Re: Re 
Anonymous Final Destination  and mail submission:

>>If you are "final destination" (ie: Are an SMTP Server acting as a 
>>MTA due to being pointed to by a MX) you have to assume that the 
>>MTA that is relaying the message to you for delivery has verified 
>>that Mail From so you HAVE TO assume that it is valid/usable.
>
>This is clearly not the case.  If the DNS name in the MAIL FROM 
>address is invalid you can't send a bounce message to it anyway, so 
>you don't "HAVE TO" use it.  In a world where a significant 
>percentage of mails received have bogus MAIL FROMs and/or bogus RCPT 
>TO addresses or are undeliverable for other reasons, checking the 
>DNS name of the MAIL FROM _before_ you agree to relay mail to a 
>recipient starts to make sense.

I mostly agree with the above. My comment was directed to a statement 
(to which I was replying) that a final destination server still needs 
to validate the Mail From address just like it would if it were a MSA 
(ie: The Server that initially accepted the message for local 
delivery or relay) to the extent possible at that late stage of the 
process but has to rely on the MSA having done those checks that only 
a MSA can do. My statement was meant to only cover the cases where 
the server that is going to issue the bounce can first determine if 
sending a bounce will succeed (ie: It is to go to a valid domain 
while the userid MAY be nonexistent or while existent is not the 
correct address to send to [ie: It is spoofed]). Obviously if the 
domain does not exist (ie: There is no MX or A record) attempting to 
send a bounce is an exercise in futility. Checking for the actual 
existence of that address (ie: That there is a mailbox that can 
accept the bounce message) requires the issuing of a VEFY Command 
which many/most SMTP Servers will not respond to for security/privacy 
reasons.

Your statement that you should be "checking the DNS name of the MAIL 
FROM _before_ you agree to relay mail to a recipient" applies to the 
MSA not when (as I qualified my statement) acting as a "final 
destination" MTA Server since at that point you are not relaying but 
attempting to do delivery.

Date: Sun, 26 Jun 2005 11:31:51 -0400
From: Keith Moore <[email-masked]>
To: "Robert A. Rosenberg" <[email-masked]>
Cc: IETF-SMTP <[email-masked]>
Subject: Re: Re Anonymous Final Destination  and mail submission
Sender: [email-masked]

> If you are "final destination" (ie: Are an SMTP Server acting as a MTA 
> due to being pointed to by a MX) you have to assume that the MTA that is 
> relaying the message to you for delivery has verified that Mail From so 
> you HAVE TO assume that it is valid/usable.

This is clearly not the case.  If the DNS name in the MAIL FROM address 
is invalid you can't send a bounce message to it anyway, so you don't 
"HAVE TO" use it.  In a world where a significant percentage of mails 
received have bogus MAIL FROMs and/or bogus RCPT TO addresses or are 
undeliverable for other reasons, checking the DNS name of the MAIL FROM 
_before_ you agree to relay mail to a recipient starts to make sense.

Date: Sat, 25 Jun 2005 17:08:23 -0400
To: "IETF-SMTP" <[email-masked]>
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: Re: Re Anonymous Final Destination  and mail submission
Sender: [email-masked]

At 15:15 +0100 on 06/25/2005, Willemien wrote about Re: Re: Re 
Anonymous Final Destination  and mail submission:

>  > Since authorization is not required for final destination transactions, it
>>  is anonymous in the sense that you are not required to perform any kind of
>>  sender "checking" or "validation" to accept the transaction for a local
>>  final destination message.   You don't know if MAIL FROM is good or bad
>>  until it is required to be used like in a bounce which will be too late in
>>  regards to the spam spoofing problem, and for the growing eVirus problems
>>  the worst mode of operation you can be in.
>
>That's what I meant
>If you do not know if the  MAIL FROM is good or bad do not use it.

If you are "final destination" (ie: Are an SMTP Server acting as a 
MTA due to being pointed to by a MX) you have to assume that the MTA 
that is relaying the message to you for delivery has verified that 
Mail From so you HAVE TO assume that it is valid/usable.

From: "Willemien" <[email-masked]>
To: "Hector Santos" <[email-masked]>
Cc: "IETF-SMTP" <[email-masked]>
Subject: Re: Re: Re Anonymous Final Destination  and mail submission
Date: Sat, 25 Jun 2005 15:15:40 +0100
Sender: [email-masked]

> > I am trying to figure out what you mean by "Anonymous Final Destination"
> > (AFD) transactions
>
> Authorized transactions, either explicitly or implicitly, implies the
sender
> is known by some BCP method in place.   Typically a prior relationship is
> established.  In general (BCP), the only time authorization is required is
> when the sender is attempted to do routing or relaying of mail.  In this
> case, when routing is request, authorization is required, this the
> authorized session is not anonymous.
>
> Since authorization is not required for final destination transactions, it
> is anonymous in the sense that you are not required to perform any kind of
> sender "checking" or "validation" to accept the transaction for a local
> final destination message.   You don't know if MAIL FROM is good or bad
> until it is required to be used like in a bounce which will be too late in
> regards to the spam spoofing problem, and for the growing eVirus problems
> the worst mode of operation you can be in.

That's what I meant
If you do not know if the  MAIL FROM is good or bad do not use it.

>
> AFD is the top #1 reason for the spam problem.   Spammers are exploiting
the
> huge network of machines behaving in AFD mode (as required by RFC
standards)
> where validation is not required and no taking place for final destination
> transactions.
>
It is more the problem that bounces are used in an inappropriate way.
Bounces should (in my opinion) only be send:
- if the mail domain is invalid /unreachable
- after a bounce reply (SMTP 5xx error)
- maybe some other situations not

Bounces should NOT be send:
If the MDA after accepting the email, finds that it cannot deliver it.
(The MDA should not accept the email in the first place)
maybe an exception here for large ISPs and large organisations
Emails containing virusses, expecially do not bounce the virus back.

> If a spammer was going to use your machine to route mail, it could only do
> so authorized machine, in which case, it is not anonymous.   The exception
> to this is an open relay.
>
> > Is your opinion simply stated  "Do not send  bounce messages if you
> haven't
> > checked the MAIL FROM: or EHLO identity, only use  error replies during
> the
> > SMTP session"
>
> No.  I am not sure where that came from.
>

It was just my (maybe to) simple conclusion of the whole AFD problem

> > Or do you mean something more sophisticated?
>
> Sorry, I am not sure in what context you are asking the question.
>
> > But unfortunedly, it has nothing to do with mailsubmission,
mailsubmission
> > in general doesn't happen at the receiving domain. and at the MSA
(sending
> > domain) it is impossible to check the localpart of the receiving domain,
> > this would somehow go against the grain of SMTP, that relies on STORE
and
> > forward.
> > This  would need the MSA to connect in directly to the receiving MDA for
> > checking the RCPT TO address, while  receiving the email. (so no storing
> at
> > the MSA)
>
> Hmmm I think I understand your question now....
>
> The receiver MTA will know the type transaction - Local Or Remote when the
> RCPT TO address is provided.
>
> If the address is local, that implies it is part of your local domains or
> hosted domains if you are ISP.  In this case,  by best current practices,
no
> authorization is required.   This is what makes the Internet work -
> otherwise you will never be able to receive unsolicated mail from
legitimate
> people.
>
> If the address is remote, that implies, this is not your under control, it
> is not your domain that you own or are hosting.    You can perform a check
> to see if it really exist somewhere else, but that isn't typically done.
> But either way,  assuming the address does exist, it is not yours thus it
is
> a remote domain and the best current practice is to only allow this if the
> sender is authorized to route mail.
>
> This is what makes the internet work in our vast integrated public email
> network that we have.  If everyone had to be authorized to send local
mail,
> it wouldn't work very well.
>
> In my view, the concept of ESMTP AUTH vs. 2476 (mail submission protocol -
a
> terrible name, but it is what it is) is either explicit or explicit.
>
> Think of FTP.  In FTP we have:
>
>     FTP Implicit SSL
>     FTP Explicit SSL
>
> In implicit, we define a specific port that presumes a secured channel.
In
> explicit, the standard port is used and the client has the option to use
> switch to a secured channel.
>
> Same with SMTP.
>
> ESMTP AUTH is an optional extended SMTP protocol. It is not required.
This
> is on port 25.  This can viewed as Explicit ESMTP AUTH.
>
> 2476 at the top level is Implicit ESMTP AUTH because it is required.  No
> option. This is typically on port 587.
>
> Now, I understand 2476 says you don't have to use port 587.  Well, in my
> view, that doesn't quite enforce it then.  That's not the standard network
> behavior.
>
> Sure, you can probably have a dedicated machine that enforces ESMTP AUTH
on
> port 25, but than is certainly not the standard to do this and you
certainly
> will limit the email you can receive to a dedicated group of people only
> that understand your this host  on  port 25 policy.
>
> We have an option for ESMTP AUTH:
>
>     [X] Enable ESMTP AUTH
>           [_] Force for all connections.
>
> If the sysop enabled this sub-option, then he effectively has prepared a
> "closed" system.  It can't be used for public internet.
>
> --
> Hector Santos, Santronics Software, Inc.
> http://www.santronics.com

I think the MSA works different from your idea of an MTA.

In the following I make a distinction between posting == submission and
mailing == getting the mail to its (external) destination.
(sending is not used)

First of all:
The MX dns records should NOT  point to an MSA so  mail from anonymous
/external users should not be  mailed  to an MSA. If  (by lack of hosts or
something similar) the MSA and the MTA have to share an IP address the MTA
gets port 25 and the MSA gets port 587)

MSA should know their clients, there need to be a prior relationship, and
the clients (MUA) should  post all there emails to just one host (MSA) .
(the smarthost principle)
The MSA checks if the client is allowed to mail emails and then mails the
email over the internet.

For LAN's there is no need to use port 587, local users (MUA) can post to
the MSA just over port 25. again without using MX records.
Some even think that all LAN users are by definition authorised to mail
trough the MSA so in this case there is no need to authorise.

Roaming users  post there emails to the MSA by using port 587 (preferably)
or port 25, again the MSA checks if the user is authorised and if so, mails
the email towards its destination.
Here port 587 is also chosen because some ISP's (for their reasons) block
traffic on port 25 that is not directed to their SMTP servers.

A curiosity exists, what if a unrecognised client posts mail for a known
local user.
An MSA should /can reject the email  while an MTA MUST accept it.
But this is al a bit  beyond the discussion, if it was only because
unrecognised clients will mostly use the MTA (with MX pointing to it) in
preference to an MSA, (without MX pointers)

MSA can be seen as just  a major extension of ESMTP AUTH. with using a
different port to reduce the double usage of port 25 but there is a bit more
behind it.

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked], [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: Last Call: 'Email Submission Between Independent Networks' to BCP
Date: Tue, 21 Jun 2005 19:53:18 -0400
Cc: Frank Ellermann <[email-masked]>, [email-masked]
Sender: [email-masked]

On Tue June 21 2005 17:00, Frank Ellermann wrote:
> 
> Bruce Lilly wrote:

>  [1.5 MB PDF]
> > Heavens to Betsy, a whole floppy disk's worth of space :-).
> 
> Won't impress my nice USR Courier and AcroReader 3.0 -

I can't help that.  The document comments indicate that it was generated
from MS PowerPoint by Windows Acrobat Distiller in 1.3 (Acrobat 4.x) PDF
format.

> > It is unclear what you're referring to; specific
> > sections of RFC 1958 were referenced.
> 
> This "incompatible with the Internet architecture",
> your death sentence.  You could as well quote KISS
> (3.5), the principle of constant change (1), build
> on the work of others (3.2), running code (3.14),
> or don't wait for perfect solutions (3.7).  In some
> way or another all relevant for hutzler-spamops-04.

Perhaps. You're welcome to comment on issues that you think are
important.  I picked the end-to-end issue (as reaffirmed by RFCs
3426 and 3439), security issues, and consistency and clarity of
terminology.  There may well be other issues; due to the ambiguity
and vagueness (in part due to lack of clear and consistent
terminology) it's not currently possible to tell from the draft
as written.

> > security multiparts (not referenced by RFC number,
> > which is 1847
> 
> You never stop to amaze me with RfC numbers I have
> never before heard of...  oh, that stuff, okay, now
> where's that related to MSA and MDA considerations ?

It's related to the concept of authentication/authorization and
the end-to-end principle.  It seems rather silly for some random
MTA to decide whether or not some human sender or machine is
allowed to send a message to me claiming to be from some author.
If the existing mechanisms which are capable of providing true
end-to-end authentication are used, there is absolutely no reason
for some intermediate MTA to try to play nanny.
 
> Okay, I'd interpret it as the address identifying the
> mailbox in the forward path.
[...]
> So "RCPT-TO address" is a forward-path minus route,

The point is that if the perfectly fine terminology used in the
primary reference is used in the draft itself, there is no need
for interpretation (i.e. "guessing").

> > other mail system components cannot determine whether
> > or not delivery is "final"
> 
> Then they have to assume that it is, and if something
> beyond their control has its own ideas it's responsible
> to get it right, e.g. a mailing list.
> 
> > See above and RFC 3028 (esp. sect. 4.3).
> 
> MUA-stuff, a MUA claiming to be no MUA is still a MUA.

No, RFC 3028 is Sieve, which "is not tied to any particular
operating system or mail architecture"; it can be run in an MUA,
but can also be run elsewhere.  See the RFC 3028 Abstract and
Introduction.

> > think about the word "gateway" for a moment or two.
> 
> Yes, MUAs claiming to be a gateway are often a PITA.

No, nothing to do with MUAs.  An MTA acting as a gateway might
indeed make final *SMTP* delivery, but not final delivery; moreover
a subsequent gateway may reintroduce the message into SMTP.  In
other cases, the MTA may be unable to determine whether delivery
is to a message store or to a temporary spooling area for subsequent
gateway processing.

In particular, your interpretation about "reject instead of accept
and later bounce" is inapplicable in the case of many gateways; the
gateway has no way to determine validity of the recipient mailbox
equivalent -- if it turns out to be invalid, a "bounce" may well be
the only way to provide an indication to the originator.  [in more
general terms, that interpretation means little if multiple "hops"
of store-and-forward (SMTP) is used; if one late hop results in a
permanent error reply code (or a timeout, etc.) the intermediate
MTA that accepted and stored the message before attempting to send
to the MTA or MDA that might be able to reject the message still
needs to send a "bounce", as that is specifically required by RFC
2821 sections 2.1, 3.3, 3.7, 4.1.1.4, 4.2.5, 6.1.]

> > So is it a person, a piece of software, a host, an IP
> > address, or what?
> 
> It's something with an IP connecting to port 25 or 587
> saying HELO or EHLO.  And if that's you using telnet
> it's perfectly okay.

But it's still not clear what it is that is supposed to be
authenticated.

> >> Yes, it's simply the 2476(bis) 4.3 MUST, see above.
> > Where's the justification for an imperative?
> 
> In section 4.3 of 2476(bis), without authentication it
> would be an open relay and no MSA.

The draft still lacks a justification corresponding to BCP 14
"actually required for interoperation or to limit behavior which has
potential for causing harm (e.g., limiting retransmisssions)  For
example, they must not be used to try to impose a particular method
on implementors where the method is not required for interoperability".

> > No. No matter what
> 
> Now wait, my next statement belonged to this part:
> 
> | If it's coupled with 2476(bis) "enforced submission rights".
> 
> > there is an open window that an attacker can exploit.
> 
> He had to get the "enabled" IP and had to know the MAIL FROM.

Yes -- see the "evil twin" discussions on the IETF discussion list
related to the draft under discussion.
 
>  [rfc2223bis-08.txt]
> > "Active" and "IESG Evaluation" according to the official
> > Internet-Drafts Database.  Your source?
> 
> A local copy of the draft, line 11:  "Expires: February 2005".

Expiration date can be extended (w/o changing the draft text) by request
of the author or IESG.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Last Call: 'Email Submission Between Independent Networks' to BCP
Date:  Tue, 21 Jun 2005 23:00:45 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 157
Cc: [email-masked]
Sender: [email-masked]

Bruce Lilly wrote:

> Credit goes to Henrik Levkowetz' idnits program.

ACK.  [After some debugging with his help I found a
way to use the Web service, it works fine with Lynx]

 [1.5 MB PDF]
> Heavens to Betsy, a whole floppy disk's worth of space :-).

Won't impress my nice USR Courier and AcroReader 3.0 -
I'll wait until you quote it again for an I-D where I
promised that it would survive your review.

>>>    o Too much text is ambiguous or vague
>> Statements like this are vague and therefore almost
>> useless.
> That's in a summary and is supported by detailed
> comments on specific draft text which is ambiguous
> and/or vague.

Maybe swap "specific examples" and "comments".  Or
replace "comments" by "summary".  Or add "specific
examples shown below" to the "serious defects".

I simply tried to read it top down (jumping from
RfC 2476bis to the I-D and back in another window).

>> please remove [R21] from your list.

> It is unclear what you're referring to; specific
> sections of RFC 1958 were referenced.

This "incompatible with the Internet architecture",
your death sentence.  You could as well quote KISS
(3.5), the principle of constant change (1), build
on the work of others (3.2), running code (3.14),
or don't wait for perfect solutions (3.7).  In some
way or another all relevant for hutzler-spamops-04.

> security multiparts (not referenced by RFC number,
> which is 1847

You never stop to amaze me with RfC numbers I have
never before heard of...  oh, that stuff, okay, now
where's that related to MSA and MDA considerations ?

All they have to decide is "is this a submission ?",
"if yes, when should I accept it ?", "is this for
a local user ?", and "if no, what should I do ?".

Not at all related to the DATA or a potential MIME
multipart/signed or multipart/encrypted body.  Dave
is listed in the RfC 1847 credits, so he would know
if there's any problem.  I certainly don't see it.

> e.g. "RCPT-TO address" vs. RCPT TO path (no hyphen
> and "path" as used in RFCs 821, 2821)

Okay, I'd interpret it as the address identifying the
mailbox in the forward path.  Or as RfC 821 put it,
"the mailbox is an absolute address", "to emphasize
the distinction between an adress and a route".

So "RCPT-TO address" is a forward-path minus route,
what else should it be.  The hyphen might be a typo.

 [skipping some text where we probably disagree]
> The underlying problem may be the lack of definition
> of an MDA.

Point, 2476(bis) offers only MUA, MSA, and MTA.  And
your concept makes sense, but not in conjunction with
some ideas in the draft.

> other mail system components cannot determine whether
> or not delivery is "final"

Then they have to assume that it is, and if something
beyond their control has its own ideas it's responsible
to get it right, e.g. a mailing list.

> See above and RFC 3028 (esp. sect. 4.3).

MUA-stuff, a MUA claiming to be no MUA is still a MUA.

> think about the word "gateway" for a moment or two.

Yes, MUAs claiming to be a gateway are often a PITA.

  [submitting entity]
>> 2476(bis) defines MSA and MUA, it must be the latter
>> in this case.

> So is it a person, a piece of software, a host, an IP
> address, or what?

It's something with an IP connecting to port 25 or 587
saying HELO or EHLO.  And if that's you using telnet
it's perfectly okay.

>> Yes, it's simply the 2476(bis) 4.3 MUST, see above.
> Where's the justification for an imperative?

In section 4.3 of 2476(bis), without authentication it
would be an open relay and no MSA.  Normally I'd hate
"green MUST be a colour" statements, maybe there's an
odd weak point in the draft and 2476(bis).

> (draft-under-discussion punctuation mode on)
> If you, think, that adding random, commas, improves
> readability, you, are mistaken.  It obfuscates, the
> meaning.
> (bizarre punctuation mode off)

Only typos, nothing bizarre about it from my POV.

  [SMTP-afer-POP]
>> Depends on how you do it, it can be perfectly sane and even
>> better than the non-standard SMTP AUTH "LOGIN" scheme, or
>> PLAIN without TLS (not allowed, but not everybody knows it).

> No. No matter what

Now wait, my next statement belonged to this part:

| If it's coupled with 2476(bis) "enforced submission rights".

> there is an open window that an attacker can exploit.

He had to get the "enabled" IP and had to know the MAIL FROM.

> Also, basic POP3 uses plaintext USER and PASS commands;

When I said _can_ be better than AUTH "LOGIN" it was of course
not about USER PASS.  But APOP can be already slightly better.

>> My copy of RfC 3700 lists STD 10 => RfC 821 + 1870.

> std-index also says RFC 974.  std-index and rfc-index both
> say 821 et al. are obsoleted by 2821, and 2821 itself says
> so.

RfC 2821 is a "proposed standard", and for some of the more
obscure RfC 821 features like SAML or SOML it says "read 821".

Besides RfC 821 had a logical concept of MAIL FROM, at least
in theory, where RfC 2821 offers only a "we broke it, sorry".

 [rfc2223bis-08.txt]
> "Active" and "IESG Evaluation" according to the official
> Internet-Drafts Database.  Your source?

A local copy of the draft, line 11:  "Expires: February 2005".

                           Bye, Frank

From: "Hector Santos" <[email-masked]>
To: "Willemien" <[email-masked]>
Cc: "IETF-SMTP" <[email-masked]>
Subject: Re: Re Anonymous Final Destination WAS : request discussion of two documents on SMTP relaying
Date: Tue, 21 Jun 2005 13:11:43 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

----- Original Message -----
From: "Willemien" <[email-masked]>
documents on SMTP relaying

> I am trying to figure out what you mean by "Anonymous Final Destination"
> (AFD) transactions

Authorized transactions, either explicitly or implicitly, implies the sender
is known by some BCP method in place.   Typically a prior relationship is
established.  In general (BCP), the only time authorization is required is
when the sender is attempted to do routing or relaying of mail.  In this
case, when routing is request, authorization is required, this the
authorized session is not anonymous.

Since authorization is not required for final destination transactions, it
is anonymous in the sense that you are not required to perform any kind of
sender "checking" or "validation" to accept the transaction for a local
final destination message.   You don't know if MAIL FROM is good or bad
until it is required to be used like in a bounce which will be too late in
regards to the spam spoofing problem, and for the growing eVirus problems
the worst mode of operation you can be in.

AFD is the top #1 reason for the spam problem.   Spammers are exploiting the
huge network of machines behaving in AFD mode (as required by RFC standards)
where validation is not required and no taking place for final destination
transactions.

If a spammer was going to use your machine to route mail, it could only do
so authorized machine, in which case, it is not anonymous.   The exception
to this is an open relay.

> Is your opinion simply stated  "Do not send  bounce messages if you
haven't
> checked the MAIL FROM: or EHLO identity, only use  error replies during
the
> SMTP session"

No.  I am not sure where that came from.

> Or do you mean something more sophisticated?

Sorry, I am not sure in what context you are asking the question.

> But unfortunedly, it has nothing to do with mailsubmission, mailsubmission
> in general doesn't happen at the receiving domain. and at the MSA (sending
> domain) it is impossible to check the localpart of the receiving domain,
> this would somehow go against the grain of SMTP, that relies on STORE and
> forward.
> This  would need the MSA to connect in directly to the receiving MDA for
> checking the RCPT TO address, while  receiving the email. (so no storing
at
> the MSA)

Hmmm I think I understand your question now....

The receiver MTA will know the type transaction - Local Or Remote when the
RCPT TO address is provided.

If the address is local, that implies it is part of your local domains or
hosted domains if you are ISP.  In this case,  by best current practices, no
authorization is required.   This is what makes the Internet work -
otherwise you will never be able to receive unsolicated mail from legitimate
people.

If the address is remote, that implies, this is not your under control, it
is not your domain that you own or are hosting.    You can perform a check
to see if it really exist somewhere else, but that isn't typically done.
But either way,  assuming the address does exist, it is not yours thus it is
a remote domain and the best current practice is to only allow this if the
sender is authorized to route mail.

This is what makes the internet work in our vast integrated public email
network that we have.  If everyone had to be authorized to send local mail,
it wouldn't work very well.

In my view, the concept of ESMTP AUTH vs. 2476 (mail submission protocol - a
terrible name, but it is what it is) is either explicit or explicit.

Think of FTP.  In FTP we have:

    FTP Implicit SSL
    FTP Explicit SSL

In implicit, we define a specific port that presumes a secured channel.  In
explicit, the standard port is used and the client has the option to use
switch to a secured channel.

Same with SMTP.

ESMTP AUTH is an optional extended SMTP protocol. It is not required.  This
is on port 25.  This can viewed as Explicit ESMTP AUTH.

2476 at the top level is Implicit ESMTP AUTH because it is required.  No
option. This is typically on port 587.

Now, I understand 2476 says you don't have to use port 587.  Well, in my
view, that doesn't quite enforce it then.  That's not the standard network
behavior.

Sure, you can probably have a dedicated machine that enforces ESMTP AUTH on
port 25, but than is certainly not the standard to do this and you certainly
will limit the email you can receive to a dedicated group of people only
that understand your this host  on  port 25 policy.

We have an option for ESMTP AUTH:

    [X] Enable ESMTP AUTH
          [_] Force for all connections.

If the sysop enabled this sub-option, then he effectively has prepared a
"closed" system.  It can't be used for public internet.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked], [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: Last Call: 'Email Submission Between Independent Networks' to BCP
Date: Tue, 21 Jun 2005 11:25:24 -0400
Cc: Frank Ellermann <[email-masked]>, [email-masked]
Sender: [email-masked]

On Mon June 20 2005 21:40, Frank Ellermann wrote:

> Bruce Lilly wrote:
> 
> > Checking nits according to
> > http://www.ietf.org/ID-Checklist.html:
> [...]
> Okay, you found nits above the typo level, draft -04
> has to be fixed before it can be "last called" again.

Credit goes to Henrik Levkowetz' idnits program.

> > [R5.editor62] may be useful
> 
> An 1.5 MB PDF, so that is most probably irrelevant to
> create plain text 20 KB Internet Drafts with 10 pages.

Heavens to Betsy, a whole floppy disk's worth of space :-).
It gives advice on writing comprehensible text (slides 42 through 54
are pertinent to the draft under discussion) among other things.

> >    o Too much text is ambiguous or vague
> 
> Statements like this are vague and therefore almost useless.

That's in a summary and is supported by detailed comments on specific
draft text which is ambiguous and/or vague.

> > [X] incompatible with the Internet Architecture (RFC 1958).
> 
> This "exponential-growth-info" is no standard of any kind,
> please remove [R21] from your list.

It is unclear what you're referring to; specific sections of RFC 1958
were referenced.
 
> > [X] incompatible with one or more approved Internet
> > specifications
> 
> Care to name one or more specifications ?

Aside from RFC 1958, the review specifically mentioned issues related
to RFCs 2821, 2476, BCP 14, and security multiparts (not referenced by
RFC number, which is 1847).
 
> > [X] uses non-standard, inconsistent, or poorly-defined
> > terminology
> 
> Which "standard terminology" are you talking about ?

Several cases were specifically mentioned (e.g. "RCPT-TO address"
vs. RCPT TO path (no hyphen and "path" as used in RFCs 821, 2821)).
 
> > [X] not backwards compatible with widely deployed,
> > standards-conforming infrastructure
> 
> If there's a problem with 2476bis I didn't see it,
> except from the obvious s/2476/gellens-submit-02/

E.g. the conflict between 2476 et seq "MAY choose to use port 25" vs.
draft under discussion "MUST support the SUBMISSION port".  There are
of course other issues as listed in the review.
 
> > o Draft section 2 states that an MSA is always used
> > for "submission", but that is not universal current
> > practice.  Many service providers support only MTAs,
> > and messages may be initially transported by an MUA
> > sending to an MTA.
> 
> As defined in 2476bis that's a special case of an MSA:
> 
> | A site MAY choose to use port 25 for message
> | submission, by designating some hosts to be MSAs and
> | others to be MTAs.

No, while 2476 permits use of port 25 for an MSA, it does not specify
that use of port 25 automatically changes an MTA into an MSA.  MTA
transfer (other than gateways) precludes message modification; an
MSA is explicitly permitted by 2476 to modify message content without
notice to or approval of the client or author, and the draft's "treat
as submission" appears to encourage such unauthorized modification *by
MTAs*.
 
> And as far as I can tell it this _is_ current practice.

Unauthorized message modification may indeed be current practice in
*some* places, but it's not *best* current practice, and in any event
although the abbreviation "BCP" stands for best current practice, the
BCP series of RFCs has specific uses as specified in BCP 9 and as
paraphrased in the review; the draft under discussion fails to meet
several of the requirements for BCP as noted in the review (and by
others in IETF discussion list comments).

> > o The same draft section refers to an "inbox", which
> > is not defined.
> 
> Actually "inbox" is defined in the next statement,

I see no *definition*.  Nothing resembling one.

> > o In some cases, an MDA may continue transport of a
> > message based on per-mailbox forwarding, aliasing, or
> > list expansion operations.
> 
> If it's no final delivery it's no MDA.

The underlying problem may be the lack of definition of an MDA.  As
far as I'm concerned, aliasing, forwarding, and list expansion take
place at an MDA, when the mailbox local-part is interpreted.  Such
interpretation is a delivery operation rather than a transport operation
as it involves changes to the SMTP envelope.  That the same message
(RFC 2822 sect. 3.6.4) is again transported as a result of delivery
to a mailbox simply means that the delivery isn't "final" (and in
practice this may happen via a distributed mechanism such as a Sieve
script, such that other mail system components cannot determine whether
or not delivery is "final").
 
> > "It is sometimes difficult for an SMTP server to
> > determine whether or not it is making final delivery".
> 
> Difficult or not, it will decide this, otherwise it's a
> Schroedinger-MTA or science fiction.

See above and RFC 3028 (esp. sect. 4.3).  Also, think about the word
"gateway" for a moment or two.
 
> > Draft section 3 refers to "sender", which is not
> > defined.
> 
> It's defined in STD 10, everybody knows what it is.
> And in the context of chapter 3 it's the submitter.

RFC 821 refers to "sender-SMTP" and to "the sender" and "the sender
mailbox", but provides no definition.  Use is not sufficiently
consistent to infer a definition; e.g. "the sender of the HELP command"
appears to refer to an SMTP client implementation (maybe "sender-SMTP"),
but a client certainly need not have a "sender mailbox".

RFC 1869 does not contain the word "sender" at all, and RFC 974 uses
the word exactly once, not as a definition.

> > it is unclear what is meant by "sender authentication".
> 
> The complete chapter 3 explains what it's supposed to
> be for an MSA, "submitter authentication".

The draft doesn't say what is being used (IP address? HELO/EHLO domain?
MAIL FROM path? message header field content? something else?), and
because some of those have been attempted to be used in inappropriate
circumstances, causing harm to the Internet, a vague blanket statement
such as in the draft under discussion is unsuitable as BCP or as a
Standards Track RFC precisely because it encompasses those harmful
practices.  The draft needs to be specific about precisely what may
and may not be used as a basis for authentication/authorization/validation,
of what/who, by what/whom, under which circumstances, and for what
specific purposes.  In addition, at least something needs to be said
about some specific methods which have known limitations or flaws.

> > Section 3 also refers to "the final MTA-to-MDA
> > transmission", ignoring the caveat in [R10.RFC2821].
> 
> "551 user not local" is an old and simple concept, not
> the stuff to write a new BCP about.  The idea in the
> draft is to reject mails to unknown local users a.s.a,p.
> instead of first accept and later bounce such crap.

That's not what the draft says.  Nor is it at all clear that that is
the intent.  Indeed, the draft never once mentions "bounce" or the
more precise "notification".
 
> > It also refers to "MDA-to-MUA delivery"
> 
> What term do you propose to catch all these wild and
> wonderful ways to get mail from an MDA to the user ?
> This "MUA" could be a Webmail interface, it could be
> IMAP, POP3, some ETRN or ATRN trick, UUCP, what else.

None of webmail, POP3, nor IMAP involve delivery; they are either "pull"
or "access" mechanisms associated with a message store of some sort.
ETRN is specifically prohibited by RFC 2476 et seq.   "ATRN" is only
mentioned in RFC 2645, which has been stuch at Proposed Standard for
six years, presumably because there aren't two implementations.  UUCP
is a low-level transport mechanism which is incapable of "to-MUA
delivery"; it sends files that may be saved to a message store.

> Maybe "mailbox-by-MUA access" ?

The (convoluted and vague) text appears to be discussing MDAs, not
recipient MUAs.  I see no reason to mention recipient MUAs at all.
 
> > The same draft section refers to a "relationship
> > between client and server" but does not specify
> > what the nature of the supposed relationship is
> 
> This "supposed relationship" can be whatever the site
> wants it to be,

As noted above, that's a problem because some of the "whatever" is
harmful.

> > "the MDA can determine that it will be effecting
> >  final delivery" in direct contradiction to the
> > statement quoted above from the approved Internet
> > specification contained in [R10.RFC2821].
> 
> Yes, something might be odd here, because if it's
> not effecting final delivery it's no MDA, and that
> might be a kind of circular definition.

No definition at all.
 
> > undefined term "submitting entity"
> 
> 2476(bis) defines MSA and MUA, it must be the latter
> in this case.

So is it a person, a piece of software, a host, an IP address, or
what?

> > That bullet point uses a BCP 14 imperative keyword
> 
> Yes, it's simply the 2476(bis) 4.3 MUST, see above.

Where's the justification for an imperative?
 
> > the meaning is unclear; does this refer to an implied
> > permission to mangle message content?
> 
> Submit / MSA is defined in 2476(bis) and perfectly clear.

It's not at all clear (specific 2476 et seq issues were discussed on
the IETF discussion list several months ago), and the draft under
current discussion is unclear about what "treat as submission" entails
(as noted by several reviewers).
 
> The MDA oddity again.  The idea is simply "reject instead of
> accept and later bounce",

That's your interpretation, not anything explicitly stated in the
document under discussion.   For Standards Track and BCP documents, we
need a clear specification, not something that will be interpreted in
dozens of different, incompatible, non-interoperable ways.

> > * Bizarre misuse of punctuation.
> 
> Spelling flames were already lame when I was much younger. :-(

The comment has nothing to do with spelling. 

(draft-under-discussion punctuation mode on)
If you, think, that adding random, commas, improves readability, you,
are mistaken.  It obfuscates, the meaning.
(bizarre punctuation mode off)

> > The figure and text also presume the availability of a
> > suitable MSA using port 587; both presumptions do not
> > conform to universal current practice.
> 
> It's the point of this text to offer MSAs for roaming users
> even under "bizarre conditions" like a blocked port 25.

The text can offer whatever its authors like.  The reality is that
many service providers do not provide MSAs, some that do choose to
use port 25 (as explicitly permitted by RFC 2476 et seq.), and that
combinations of requirements in the draft will cause serious damage
to the Internet unless a phased roll-in is used.

> > Draft section 5 mentions POP-before-SMTP, which has known
> > security defects
> 
> Depends on how you do it, it can be perfectly sane and even
> better than the non-standard SMTP AUTH "LOGIN" scheme, or
> PLAIN without TLS (not allowed, but not everybody knows it).

No. No matter what, there is an open window that an attacker can
exploit.  Also, basic POP3 uses plaintext USER and PASS commands;
use of that with SMTP-after-POP gives an attacker access to not
only SMTP, but to POP as well.
 
> Removing features instead of doing it right or fixing them
> is a stupid strategy.

Opening a window for exploit by attackers is a stupid strategy.

> My copy of RfC 3700 lists STD 10 => RfC 821 + 1870.

std-index also says RFC 974.  std-index and rfc-index both say 821 et al.
are obsoleted by 2821, and 2821 itself says so.
 
> > (draft-rfc-editor-rfc2223bis-08.txt), July 2004.
> 
> Expired.

"Active" and "IESG Evaluation" according to the official Internet-Drafts
Database.  Your source?

> > [R12.FYI36]
> [...]
> > RFC 2828, May 2000.
> 
> Oops, there it is.  Note that 2476bis also doesn't use it,
> nothing forces authors to use a glossary they don't like.

True, but the draft's security considerations section is unacceptable,
and as it needs a rewrite, the authors should consult the appropriate
guidelines (BCP 72) and use standard terminology (FYI 36).  They can
of course ignore both, at the risk of having to rewrite yet again.

From: "Willemien" <[email-masked]>
To: <[email-masked]>
Subject: Two kinds of Submission
Date: Tue, 21 Jun 2005 15:26:17 +0100
Sender: [email-masked]

I  tried to follow the discussion about mailsubmission draft (Email
Submission Between Independent Networks) and RFC2476bis what the MSA is
allowed to do and not.

But I think we are missing a point.
There are (at least) two kinds of MSA's
I would call them
1) Organisational MSA
2) Internet (ISP)  MSA
(If you have better names please name them)

And I can not find a reference to which kind of MSA is referred in the Email
Submission Between Independent Networks draft and what the consequences are.

To describe the two types of MSA:

Organisational MSA's
the (user of) the MUA and the MSA is  part of the same organisation and the
MSA is therefore allowed to do almost anything with a message as long as the
output is proper RFC2822/2821.
This include but are not limited to:
virusscanning
removing/changing/  adding of headers (RFC2822 and 2821)
removing attachments  MIME parts
encryption/decryption
adding headers and footers to the email body
the draft should only give guidelines and suggestions for this type of MSA.
(so that the output is proper RFC2822/2821.)
In extreme cases the MSA is even allowed to refuse the message all together.

Internet MSA's are not part of the same organisation and should only do:
virusscanning
adding necessary RFC 2822 headers
adding trace headers (RFC 2821)
and other options that should be an explicit part of the contract between
the organisation and her internet provider)

From: "Willemien" <[email-masked]>
To: <[email-masked]>, "Hector Santos"  <[email-masked]>
Subject: Re Anonymous Final Destination WAS : request discussion of two documents on SMTP relaying
Date: Tue, 21 Jun 2005 14:59:26 +0100
Sender: [email-masked]

>
> However, with that said,  the key problem with both documents is that none
> of the documents clearly address the key issue of how to handle  Anonymous
> Final Destination Mail.
>
> It may be out of scope,  but it talks about making a clear distinction of
> "WHEN" authorization is required, but it does not address what I believe
is
> the #1 problem with the "Email Problem" - when it isn't required.
>
> The overall issue in Mail Hosting as it is related to TMS (Transaction
> Management and Security) issues boils down to two fundamental key parts of
> SMTP:
>
> Current Legacy Normal SMTP (BCP) Operations:
>
>  1 -  Authorization required for remote destination mail (routing)
>  2  - No authorization required for final destination mail (local
hosting).
>
<snap>
>
> The "Email Problem"  (Spam or Spoofing) begins pretty much with #2. This
is
> where over 60-80% of the problematic mail issues begin.  It the basis for
> the key abuse and exploitation of SMTP.
>
> I like to call #2 as "Anonymous Final Destination" (AFD) transactions
> because for the most part, the major exploit in SMTP is that there is no
> requirement to "verify" the sender for reception of local user and/or
local
> hosted domain transactions.  Therefore, the sender is "anonymous" in the
> sense it is not verified nor there is a requirement to do so for final
> destination mail.
>
> In other words,  systems adopting the documents can most certainly help
> people run a better server, but it doesn't change or address the
fundamental
> problem where there is abuse or non-compliance with the transaction
> parameters.    If it did, then we would not have the "Email Problem" today
> to the tune by current estimates of $13-15 billion industry cost.
>
>
> But what it doesn't say is how to handle the "verification" of the
> transaction or mail sender when a valid FINAL destination is finally
> determined.   RFC 2476 is ok, but that is not where the problem is
located -
> it is located with anonymous  final destination senders.
>
> Anyway, some might be believe this is out of scope for the documents, but
it
> is a critical aspect of the mail distribution problem we are trying to
> address.  So at a very least, this needs to be discussed at some level in
> the documents.
>
> To me, the future of SMTP and its TMS will largely depend on how we want
to
> address Anonymous Final Destination mail from several standpoints:
>
> - Verification of process entities with/ minimum SMTP compliance.
>
> - Extended SMTP Response Codes to help admins define better automated
flows,
>   (white, black, grey listing).
>
> - New R&D on extended SMTP commands, like HEAD to assist new
>   "Blast First" PAYLOAD email security protocols.
>
> - New R&D on extended SMTP  client/server handshaking requirements to
>   help define optional transaction compliancy policies.
>

I am trying to figure out what you mean by "Anonymous Final Destination"
(AFD) transactions

Is your opinion simply stated  "Do not send  bounce messages if you haven't
checked the MAIL FROM: or EHLO identity, only use  error replies during the
SMTP session"

Or do you mean something more sophisticated?
.
PS. I  do agree with this idea.
"If you cannot check the localpart directly, do not send bouncemail to
unchecked addresses."

But unfortunedly, it has nothing to do with mailsubmission, mailsubmission
in general doesn't happen at the receiving domain. and at the MSA (sending
domain) it is impossible to check the localpart of the receiving domain,
this would somehow go against the grain of SMTP, that relies on STORE and
forward.
This  would need the MSA to connect in directly to the receiving MDA for
checking the RCPT TO address, while  receiving the email. (so no storing at
the MSA)
But having said all that.
It doesn't imply that it is always impossible.

But maybe you wanted to say something different than I discribed above.

From: Dave Crocker <[email-masked]>
To: Willemien <[email-masked]>, <[email-masked]>, Dave Crocker <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Date: Tue, 21 Jun 2005 06:47:57 -0700
Subject: Re: draft-crocker-email-arch-04 add-in
Sender: [email-masked]

> >  I do not understand how this improves the architecture discussion.  What
> >  problems does it solve?
> >
>  One  reason was to introduce the "novice mail concepts" of mailclient and
>  mailserver in the mailarchitecture.
>  So that novices (like me) can grasp what is ment by an MUA, MTA ect.

An architecture specification is not intended as a tutorial for beginners.  That 
is a very different requirement.

An architecture document like this is intended to be a technical specification 
of functional components for a service.

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

From: "Willemien" <[email-masked]>
To: <[email-masked]>, "Dave Crocker"  <[email-masked]>
Subject: Re: draft-crocker-email-arch-04 add-in
Date: Tue, 21 Jun 2005 14:26:52 +0100
Sender: [email-masked]

>>  I was thinking about the draft and I think we need a chapter between
>>  section
>>
>>  3 and 4 about how mail looks at the host level

> I do not understand how this improves the architecture discussion.  What
> problems does it solve?

One  reason was to introduce the "novice mail concepts" of mailclient and
mailserver in the mailarchitecture.
So that novices (like me) can grasp what is ment by an MUA, MTA ect.
futher on some agents are "bound together" on one host, so you "need"  an
host / mailserver concept.

> The discussion is already considerably more complex than most folk -- 
including
> me -- would like.  It needs to be as simple as possible, while still
covering
> essential characteristics of the service.

I agree it gets considerably more complex than I guessed it would be, but
simplifying something complex as mailarchitecture doesn't help.
.
My  hope is that the draft will evolve more to an encyclopedia of the
different viewpoints on mail architecture, and that then  interlinks those
viewpoints,  than that it just descibes one or two limited viewpoints.

And this is really to get the ALL essential characteristics of the service,
otherwise we will all miss some essential characteristics and that will
devaluate this draft to scratch.

I hope that we can agree with me on this.
(that is why I  agree that there is a chapter about adminitrative actors ,
although I do not (yet) see wich essential characteristic  it offers)

BTW
I am now thinking that the chapter that I roughly drafted is more an
introduction to chapter 4 (services / mail agents  )  then a chapter on its
own.

BTW2
I also that just before this there should be a chapter on maildomains, (and
here it is really about (MX) domains not about administrative actors)
I think that Keith Moore's  MON's , an MRN's  should go in that chapter.

 It needs to be as simple as possible, while still covering
> essential characteristics of the service

Also some agents have a

From: "Hector Santos" <[email-masked]>
To: <[email-masked]>, "David MacQuigg" <[email-masked]>
Subject: Re: Solution to Windows Email Zombie Problem
Date: Tue, 21 Jun 2005 04:15:09 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

----- Original Message -----
From: "David MacQuigg" <[email-masked]>

> I have also heard that M$ is unwilling to make its security updates
> available to unlicensed systems, which probably includes most of the
> zombies.  My guess is they are trying to turn this PR disaster into a win
> by timing the zombie shutdown so the credit for saving the email system
> goes to SenderID.
>
> Seems like someone should develop an open-source "anti-zombie" program
that
> could be used by ISPs to neuter their zombies.  Any user system that is
> open for spammers would also be open for a benign patch.  "Sorry, your
mail
> has been blocked, because your system has been infected with a mail
> worm.  <Click Here> to install a patch on your system and re-activate your
> account."  Of course, there would need to be some user education follow
on,
> and stricter measures if it happens again.

You seem to have a sense for conspiracy. :-)

Google "Article 2B" or its current name "UCITA" and see how the world will
change if new provisions to the UCC (Uniform Commence Code) and  US Federal
interstate commence laws is ratisfied.

Here are some sites with good summaries:

http://www.jamesshuggins.com/h/tek1/ucita.htm
http://www.ala.org/ala/washoff/WOissues/copyrightb/ucita/ucita.htm
http://www.badsoftware.com/networld.htm

Information Security Threats, Vulnerabilities, and Protections
http://www.cpcug.org/user/comm/UCITA-700/UCITA-700.PPT

Placing UCITA and Licensing In Context
http://www.law.washington.edu/courses/group/E589_AuWiSp05/Documents/UW-Placi
ng%20UCITA%20In%20Context-2005.ppt

There is one technology that the big software industry wants (mainly
Microsoft) that will utterly change the face of the earth - it is the holy
grail of telecommunications. If allowed, it will create a new trillion
dollar market place.

What it is?

Think "Bank Car Repossession!"   The Microsofts wants the same rights as
Banks to go into your computer to zap your software licensing and usage.

It is basically the "time share" business again.  In the future, you will
pay "usages" for applications - like $10 per Word Documentation,  $5.00 per
Excell Sheet.   This way you won't have to install or buy the whole package.
It would like be able to go to Kinkos to do a quick professional print job
on a per project basis.

Thats the market side potential - the Ciscos are gearing how for the control
of the licensing technology.

The threats are obvious - everyone and the grandma will do the same thing.
Users will lose control of what can be done on their computer.   Vendors
will be allowed to "repossessed" or ZAP your computer for lack of payment or
pirating.

etc, etc.

Check it out.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Last Call: 'Email Submission Between Independent Networks' to BCP
Date:  Tue, 21 Jun 2005 03:40:13 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 244
Cc: [email-masked]
Sender: [email-masked]

Bruce Lilly wrote:

> Checking nits according to
> http://www.ietf.org/ID-Checklist.html:
[...]
Okay, you found nits above the typo level, draft -04
has to be fixed before it can be "last called" again.

> [R5.editor62] may be useful

An 1.5 MB PDF, so that is most probably irrelevant to
create plain text 20 KB Internet Drafts with 10 pages.
Remove {R5] from your references please, or at the
very minimum add a warning about its size.

> the status as defined in [R6.BCP9] should be:

Let's assume that we know the list of possibilities,
and just state what you think...

> [X] Informational

...something's wrong if your review is longer than
the reviewed source.

>    o Too much text is ambiguous or vague

Statements like this are vague and therefore almost useless.

> [X] incompatible with the Internet Architecture (RFC 1958).

This "exponential-growth-info" is no standard of any kind,
please remove [R21] from your list.

> [X] incompatible with one or more approved Internet
> specifications

Care to name one or more specifications ?

> [X] uses non-standard, inconsistent, or poorly-defined
> terminology

Which "standard terminology" are you talking about ?

The draft references exactly three normative texts,
you might get some more recursively, so if there's a
conflict please _show_ it.  I can't check vague claims
based on what you might consider as "standard".

> [X] not backwards compatible with widely deployed,
> standards-conforming infrastructure

If there's a problem with 2476bis I didn't see it,
except from the obvious s/2476/gellens-submit-02/

> o Draft section 2 states that an MSA is always used
> for "submission", but that is not universal current
> practice.  Many service providers support only MTAs,
> and messages may be initially transported by an MUA
> sending to an MTA.

As defined in 2476bis that's a special case of an MSA:

| A site MAY choose to use port 25 for message
| submission, by designating some hosts to be MSAs and
| others to be MTAs.

And as far as I can tell it this _is_ current practice.

> o The same draft section refers to an "inbox", which
> is not defined.

Actually "inbox" is defined in the next statement, but I
agree that this definition is somewhat beside the point
in a piece of text about MDAs.

> o In some cases, an MDA may continue transport of a
> message based on per-mailbox forwarding, aliasing, or
> list expansion operations.

If it's no final delivery it's no MDA.

> "It is sometimes difficult for an SMTP server to
> determine whether or not it is making final delivery".

Difficult or not, it will decide this, otherwise it's a
Schroedinger-MTA or science fiction.

> Draft section 3 refers to "sender", which is not
> defined.

It's defined in STD 10, everybody knows what it is.
And in the context of chapter 3 it's the submitter.

> it is unclear what is meant by "sender authentication".

The complete chapter 3 explains what it's supposed to
be for an MSA, "submitter authentication".

> Section 3 also refers to "the final MTA-to-MDA
> transmission", ignoring the caveat in [R10.RFC2821].

"551 user not local" is an old and simple concept, not
the stuff to write a new BCP about.  The idea in the
draft is to reject mails to unknown local users a.s.a,p.
instead of first accept and later bounce such crap.

And that's indeed "best current practice" everywhere.

> It also refers to "MDA-to-MUA delivery"

What term do you propose to catch all these wild and
wonderful ways to get mail from an MDA to the user ?
This "MUA" could be a Webmail interface, it could be
IMAP, POP3, some ETRN or ATRN trick, UUCP, what else.

Maybe "mailbox-by-MUA access" ?

> The same draft section refers to a "relationship
> between client and server" but does not specify
> what the nature of the supposed relationship is

This "supposed relationship" can be whatever the site
wants it to be, the text simply states "MUST perform
 authentication during mail submission, based on an
 existing relationship with the submitting entity."

This MUST directly reflects the MUST in chapter 4.3
of 2476 or 2476bis, it's nothing new.

> "the MDA can determine that it will be effecting
>  final delivery" in direct contradiction to the
> statement quoted above from the approved Internet
> specification contained in [R10.RFC2821].

Yes, something might be odd here, because if it's
not effecting final delivery it's no MDA, and that
might be a kind of circular definition.

> undefined term "submitting entity"

2476(bis) defines MSA and MUA, it must be the latter
in this case.  I'm less sure about "formail" forms,
that could be a special case of "submitting entity".

> That bullet point uses a BCP 14 imperative keyword

Yes, it's simply the 2476(bis) 4.3 MUST, see above.

 [chapter 3, 3rd bullet]
> A BCP 14 imperative keyword is used with no rationale
> for such an imperative.

That's about open relays.  Treat mails from unknown
strangers to unknown strangers as submission.  In fact
this MUST is odd.  An open relay is no MSA, saying that
it MUST be an MSA (and reject the mail) is pointless,

> the meaning is unclear; does this refer to an implied
> permission to mangle message content?

Submit / MSA is defined in 2476(bis) and perfectly clear.

> The terms "authorization" and "validation" are used but
> are undefined by the draft

The draft is no _reprint_ of gellens-submit-02 (2476bis),
it's a BCP _based_ on 2476(bis).

> no specific external reference is supplied

Okay, maybe they should first submit it to the SPF-community,
we're training to get I-Ds in shape for your famous reviews,
see <http://mid.gmane.org/[email-masked]>.

So what's it, missing informative RfC 2828 reference, right ?

> The last bullet point in draft section 3 also uses undefined
> terms, BCP 14 imperative keywords with no justification or
> rationale

The MDA oddity again.  The idea is simply "reject instead of
accept and later bounce", but that's a job for the MX, not
for the MDA.

I skip your chapter 4 comments because it's getting too long.
As far as blocking port 25 is concerned I tend to agree with
you, but not to the point of a "MUST NOT".

For obvious reasons there's nothing wrong with blocking known
abuse.  And the draft just says "no recommendation".

> * Bizarre misuse of punctuation.

Spelling flames were already lame when I was much younger. :-(

> The figure and text also presume the availability of a
> suitable MSA using port 587; both presumptions do not
> conform to universal current practice.

It's the point of this text to offer MSAs for roaming users
even under "bizarre conditions" like a blocked port 25.

> Draft section 5 mentions POP-before-SMTP, which has known
> security defects

Depends on how you do it, it can be perfectly sane and even
better than the non-standard SMTP AUTH "LOGIN" scheme, or
PLAIN without TLS (not allowed, but not everybody knows it).

If it's coupled with 2476(bis) "enforced submission rights".

> ideally it would be prohibited

Removing features instead of doing it right or fixing them
is a stupid strategy.  This is an Internet Draft and not a
"security update" from whose-name-must-not-be-named.

> The normative references include:
> * RFC 821, which has been obsoleted according to the
>   rfc-index and std-index

My copy of RfC 3700 lists STD 10 => RfC 821 + 1870.

> * RFC 2476, which has Proposed Standard status

RfC 2476bis is AFAIK approved as Draft Standard.  See also:
<http://mid.gmane.org/[email-masked]>

> [R3.Instruct]
[...]
> (draft-rfc-editor-rfc2223bis-08.txt), July 2004.

Expired.

> [R12.FYI36]
[...]
> RFC 2828, May 2000.

Oops, there it is.  Note that 2476bis also doesn't use it,
nothing forces authors to use a glossary they don't like.

                          Bye, Frank

From: "Hector Santos" <[email-masked]>
To: <[email-masked]>
Subject: Re: SMTP Mail Hosting and TMS Recommendations
Date: Mon, 20 Jun 2005 15:38:31 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

Small follow up to answer a specific question you had:

----- Original Message -----
From: "Bruce Lilly" <[email-masked]>
To: <[email-masked]>
Sent: Monday, June 20, 2005 1:10 PM
Subject: Re: SMTP Mail Hosting and TMS Recommendations

> No. It is known that some hare-brained schemes are harmful (e.g. issue
> a test message using a server specified as an MX host for the MAIL FROM
> domain (if not a null reverse path); hint: consider what happens if both
> servers do that).  No "R&D" is needed to see that some schemes are
> harmful.

First, for the non-listening audience,  you are referring to what is called
a CBV (Call Back Verifier).  I 100% uncategorically disagree with you on it
technical merits especially since you have little detailed implementation
experience with it as evident by the statement.

Nonetheless, I can tell you what the current CBV implementation method is to
address your parenthetically embedded Hint statement:

            "Consider what happens if both servers do that."

Your hint refers to a "loopback" issue often incorrectly stated by CBV
opponents.

In short, the answer is that the CBV will use a NULL return path or
"PostMaster" address in some implementations for the CBV session.  Hence the
target CBV host with its own CBV support will not have an return path
address to perform a CBV loopback.

In addition, the CBV is used as a final fallback check, and for us, the CBV
resolves a majority of the SPF spoofing issues or SPF relaxed provision
issues.  I won't go into logic details since probably aren't listening
anyway, but I would recommend that you research the issues yourself before
commenting further.

Here is a simple current real life example on how it traps SPF relaxed
policies.  In the example below various test is perform, including an SPF
test which results in a neutral policy.  Once of the flaws in SPF is that it
only validates the DOMAIN part of the Return Path address.   A neutral will
trigger a CBV check and the results show it is an invalid address at the
domain host.

20050619 16:05:36 version    : 2.01 / 1.62
20050619 16:05:36 calltype   : SMTP
20050619 16:05:36 state      : rcpt
20050619 16:05:36 srvdom     : winserver.com
20050619 16:05:36 srvip      : 208.247.131.9
20050619 16:05:36 cip        : 219.249.179.187
20050619 16:05:36 cdn        : 219.249.179.187
20050619 16:05:36 from       : <[email-masked]>
20050619 16:05:36 rcpt       : <[email-masked]>
20050619 16:05:36 testorder  : FLT RBL SPF CEP CBV
20050619 16:05:36 sapfilter  : pass (time:78)
20050619 16:05:36 saprbl     : testing 187.179.249.219.sbl.spamhaus.org
20050619 16:05:36 saprbl     : testing 187.179.249.219.list.dsbl.org
20050619 16:05:36 saprbl     : testing 187.179.249.219.bl.spamcop.net
20050619 16:05:36 saprbl     : pass (time:265)
20050619 16:05:37 sapspf     : v=spf1 ip4:205.158.62.0/24
                               ip4:208.36.123.0/24
                               ip4:203.86.166.0/24
                               ip4:210.177.227.128/28
                               ip4:203.86.162.160/28
                               ip4:210.184.92.208/29
                               ip4:216.10.106.0/24 ?all
20050619 16:05:37 sapspf     : neutral (time:141)
20050619 16:05:39 sapcbv     : total mx records: 5
20050619 16:05:39 try mx     : neti-outblaze-com.mr.outblaze.com
                               ip: 205.158.62.229
20050619 16:05:39 # connecting to 205.158.62.229
20050619 16:05:39 S: 220 spf6-1s.us4.outblaze.com ESMTP Postfix
20050619 16:05:39 C: NOOP WCSAP v2.01 Wildcat! Sender Authentication
                     Protocol http://www.santronics.com
20050619 16:05:39 S: 250 Ok
20050619 16:05:39 C: HELO mail.winserver.com
20050619 16:05:40 S: 250 spf6-1s.us4.outblaze.com
20050619 16:05:40 C: MAIL FROM: <>
20050619 16:05:40 S: 250 Ok
20050619 16:05:40 C: RCPT TO: <[email-masked]>
20050619 16:05:41 S: 550 <[email-masked]>: User unknown
20050619 16:05:41 C: QUIT
20050619 16:05:41 sapcbv     : 550
20050619 16:05:41 result     : reject (0)
20050619 16:05:41 smtp code  : 550
20050619 16:05:41 reason     : Rejected by WCSAP CBV
20050619 16:05:41 wcsap finish (4812 msecs)

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

From: "Hector Santos" <[email-masked]>
To: "Keith Moore" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: request discussion of two documents on SMTP relaying
Date: Mon, 20 Jun 2005 15:07:57 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

Keith,  I didn't think it was necessary but this is just to make sure the
following specific comment of yours is not left uncooked as one person seem
to believe that the implementation did not consider your comment here.  See
inline.

----- Original Message -----
From: "Keith Moore" <[email-masked]>
To: "Hector Santos" <[email-masked]>

> > The only new concept added to our SMTP server is that the Return Path
(MAIL
> > FROM) must be verifiable - spoofed or otherwise - it must not be junk
and it
> > must reflect a valid MX host  - zombie or otherwise.
>
> Not that this is relevant to either of the documents under discussion,
> but it's not consistent with current standards to require that there be
> an MX record for the domain portion of the MAIL FROM address.  It is
> still valid to have only an A record for that address, or for that
> matter, only a AAAA record for that address (though in the latter case
> the address isn't likely to get much mail for awhile).

That's correct.  With the exception with shorter timeouts on responses, the
CBV is otherwise a full 100% SMTP client with MX and NO MX considerations.
This has not been an issue as most systems are not going to throttle
responses for more than 1 minute.   And if they do, it has been shown that
they are mostly zombie sites attempting to thwart CBV systems.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

From: "Hector Santos" <[email-masked]>
To: <[email-masked]>
Subject: Re: SMTP Mail Hosting and TMS Recommendations
Date: Mon, 20 Jun 2005 14:30:11 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

----- Original Message -----
From: "Bruce Lilly" <[email-masked]>
To: <[email-masked]>
Sent: Monday, June 20, 2005 1:10 PM
Subject: Re: SMTP Mail Hosting and TMS Recommendations [was: Hector's BCP
summary outline for SMTP]

[unnecessary meaningless comments removed]

> >    SMTP servers SHOULD publish an extended line 220 greeting response
> >    indicating the system server basic mail policy.
>
> 1. The SMTP protocol is based on reply codes; text is meant for humans
>    (RFC 2821 sections 4.2, 4.3).  The protocol is based solely on the
>    reply codes, not on text.

Bruce, what was stated in no way implied the response codes were used to
define a policy. In fact, I stated a specific 220 reply code, no other was
stated.

What was missing from section 1.2 was that extended greeting responses deals
with addressing non-compliant SMTP bulk mailers who don't know handle
multiple line responses.

Try it.  You should expect at atleast a 12-20% drop on Bulk Mailer spams.

> 5. In particular, any extension to SMTP involving negotiation (e.g.
>    of language for text) has to take place using the established ESMTP
>    negotiation mechanism.

Don't apply since you mis-understood the extended line 220 greeting response
statement.  Same with comment #6 thru #8

> >    Due to the nature of SMTP,  HELO/EHLO validation is relaxed and its
> >    verification is weak.   There are legitimate reasons as to why a
> >    client machine domain does not match the IP address.
>
> So there are "legitimate reasons ..."  (agreed), but it SHOULD
nevertheless
> be checked.   Why?  And since (because of the "legitimate reasons") the
> check provides no useful information, what is to be done with the results
> of the "validation check"?

As recommendation stated in section #2 HELO/EHLO, you should perform first
syntax checking, possibly domain literal check and a lightweight LMAP local
domain spoof check.

Example:

     CLIENT IP ADDRESS:  1.2.3.4
     HELO mail.winserver.com

Since we have 100% of our local domains, it is illegal to use this domain
with an unknown IP address.

Try it.  You will see a near 10-12% spoof trap.

I don't recommend at this point to this on an open ended basis for client
domain names simply because you dont' have control of remote domains used.
The overhead is too high and the reliability of the remote domain check is
not solid proof.   The compromise is to perform it on the domains you do
have control over, this can include a database of domains you may have and
wish to spoof-trap.

> >    Therefore, the SMTP server SHOULD highly consider to perform some
> >    form of return path validation.  How this is done is a SMTP system
> >    implementation dependent and considered as a "BLACK BOX"
> >    concept and is subject to on going R&D.

> No. It is known that some hare-brained schemes are harmful (e.g. issue
> a test message using a server specified as an MX host for the MAIL FROM
> domain (if not a null reverse path); hint: consider what happens if both
> servers do that).  No "R&D" is needed to see that some schemes are
> harmful.

That's your opinion, and I 100% sincerely respect it. But it is clearly not
the world consensus and the world should not be deemed idiots by you if you
disagree.
You should research the implementations before making unwarranted comments.

I stated it as a BLACK BOX because there isn't yet a universal method yet to
validate the specific process entity - 2821.Mail From:

Specifically, we use various BLACK BOX schemes, include SPF and CBV.  The
CBV happens to be a very good concept and essential part of our system.  It
is  rapidly growing and in use by other SMTP vendors and ISPs.

The key fact is that that MAIL FROM is a verifiable item by RFC standards
and today, the CBV is the only way to do that.

Anyway, if this is all you really have to comment on, then I think it is
pretty good.  As it should be, because its been implemented for nearly 2
years on commercial systems with high success.

I appreciate your comments.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked], [email-masked]
Subject: Re: Last Call: 'Email Submission Between Independent Networks' to BCP
Date: Mon, 20 Jun 2005 13:46:41 -0400
Cc: [email-masked]
Sender: [email-masked]

On Fri June 3 2005 09:47, The IESG wrote:
> The IESG has received a request from an individual submitter to consider the 
> following document:
> 
> - 'Email Submission Between Independent Networks '
>    <draft-hutzler-spamops-04.txt> as a BCP
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> [email-masked] or [email-masked] mailing lists by 2005-07-01.

Comments:

Internet-Drafts and RFCs are required to meet certain criteria:
[R1.Checklist] (see also references in that document), [R2.ID],
[R3.Instruct].  These can be checked by using the "idnits" tool:
[R4.idnits].  That tool noted the following regarding the document:

  idnits 1.73 (17 Jun 2005)

  draft-hutzler-spamops-04.txt:

    Checking nits according to
    http://www.ietf.org/ID-Checklist.html:
    * The document seems to lack an IANA Considerations section.
      Checking conformance with RFC 3978/3979 boilerplate...
    * The document seems to lack an RFC 3978 Section 5.1 IPR
      Disclosure Acknowledgement.

    (Expected a match on the following text:
      "By submitting this Internet-Draft, each author represents that
      any applicable patent or other IPR claims of which he or she is
      aware have been or will be disclosed, and any of which he or she
      becomes aware will be disclosed, in accordance with Section 6 of
      BCP 79.")

      (The document uses RFC 3667 boilerplate or RFC 3978-like
      boilerplate instead of verbatim RFC 3978 boilerplate.  After 6
      May 2005, submission of drafts without verbatim RFC 3978
      boilerplate is not accepted.)

    Checking nits according to
    http://www.ietf.org/ietf/1id-guidelines.txt:
      Nothing found here (but these checks do not cover all of
      1id-guidelines.txt yet).

    Miscellaneous warnings:
      None.

The wording of the document is poor.  [R5.editor62] may be useful.  Many
terms (details below) are undefined, poorly defined, or inconsistently
defined.  Many "sentences" suffer from odd placement of punctuation,
particularly commas, which make parsing those "sentences" impossible.

The (intended) status of the document is:

   [ ] Not indicated

   [ ] Experimental

   [ ] Informational

   [ ] Proposed Standard

   [ ] Draft Standard

   [ ] Internet Standard

   [X] Best Current Practice

   However, the status as defined in [R6.BCP9] should be:

   [ ] Experimental (typically denotes a specification that is part of
       some research or development effort, subject only to editorial
       considerations and to verification that there has been adequate
       coordination with the standards process)

   [X] Informational (published for the general information of the
       Internet community, does not represent an Internet community
       consensus or recommendation, subject only to editorial
       considerations and to verification that there has been adequate
       coordination with the standards process)

   [ ] Proposed Standard (generally stable, has resolved known design
       choices, is believed to be well-understood, has received
       significant community review, appears to enjoy enough community
       interest to be considered valuable, has no known technical
       omissions)

   [ ] Draft Standard (at least two independent and fully interoperable
       implementations from different code bases have been developed,
       sufficient successful operational experience has been obtained,
       unused options and features have been removed, well-understood,
       known to be quite stable both in its semantics and as a basis for
       developing an implementation, must have been Proposed Standard
       for at least six months)

   [ ] Internet Standard (significant implementation and successful
       operational experience has been obtained, characterized by a high
       degree of technical maturity and by a generally held belief that
       the specified protocol or service provides significant benefit to
       the Internet community, must have been Draft Standard for at
       least four months)

   [ ] Historic (A specification that has been superseded by a more
       recent specification or is for any other reason considered to be
       obsolete, must have been Standards Track)

   [ ] Best Current Practice (a way to standardize practices and the
       results of community deliberations, subject to the same basic set
       of procedures as standards track documents, the community's best
       current thinking on a statement of principle or on what is
       believed to be the best way to perform some operations or IETF
       process function, common guidelines for policies and operations
       which are generally different in scope and style from protocol
       standards, not well suited to the phased roll-in nature of the
       three stage standards track and instead generally only make sense
       for full and immediate instantiation)

   [ ] None of the above (see discussion)

BCP is inappropriate for the document in its current state because:

   o Too much text is ambiguous or vague

   o Specified requirements conflict with widespread current practice
     unsuitable for immediate instantiation

   o A phased roll-in would be more appropriate considering conflicts
     with current practice

   o Despite hyperbole to the contrary, the document has not been
     subject to adequate community deliberations

The document suffers from the following serious defects:

   [X] missing IANA considerations

   [X] inadequate security considerations

   [X] incompatible with the Internet Architecture (RFC 1958).  In
       particular, authentication specified is not end-to-end (RFC 1958
       section 2.3), terminology is unclear and inconsistent (section
       3.13), and security has not been adequately addressed (section 6
       and subsections).

   [X] incompatible with one or more approved Internet specifications

   [X] uses non-standard, inconsistent, or poorly-defined terminology
       which may lead to confusion, misinterpretation, and loss of
       interoperability

   [X] not backwards compatible with widely deployed,
       standards-conforming infrastructure

   [X] [R7.BCP14] is referenced, but keywords are not used, or are used
       inappropriately

Specific examples of the aforementioned issues include:

   o Draft section 2 states that an MSA is always used for "submission",
     but that is not universal current practice.  Many service providers
     support only MTAs, and messages may be initially transported by an
     MUA sending to an MTA.

   o The same draft section refers to an "inbox", which is not defined.
     It is unclear whether the term is intended to be a "mailbox", as in
     "A mailbox receives mail" [R8.RFC822], [R9.RFC2822].

   o A statement is made in the same draft section that an MDA delivers
     to the undefined "inbox" which is part of an MUA; however in
     reality, an MDA may deliver to a message store which an MUA
     accesses via a separate "pull" mechanism (e.g. file access, POP,
     IMAP).

   o In some cases, an MDA may continue transport of a message based on
     per-mailbox forwarding, aliasing, or list expansion operations.  As
     noted in [R10.RFC2821], "It is sometimes difficult for an SMTP
     server to determine whether or not it is making final delivery".

   o Draft section 3 refers to "sender", which is not defined.  It is
     unclear whether this term refers to an SMTP client or to some user
     or to a mailbox ([R9.RFC2822]) or to some other entity (or indeed
     if the term is inconsistently used).  With no definition of
     "sender", it is unclear what is meant by "sender authentication".

   o Section 3 also refers to "the final MTA-to-MDA transmission",
     ignoring the caveat in [R10.RFC2821].

   o It also refers to "MDA-to-MUA delivery" contrary to actual
     operation (use of access protocols by MUAs as noted above).

   o The same draft section refers to a "relationship between client and
     server" but does not specify what the nature of the supposed
     relationship is; it is possible that what is meant is that there
     may be a contractual agreement between a user responsible for
     initiating message transfer (but that is not a "client" as that
     term is used in relevant approved Internet specifications relating
     to the mail system) and the administrative entity operating an MSA
     (but that administrative entity is not itself a "server" as that
     term is used).

   o The same section claims that "the MDA can determine that it will be
     effecting final delivery" in direct contradiction to the statement
     quoted above from the approved Internet specification contained in
     [R10.RFC2821].

   o While the qualifying word "typically" appears in part of the
     compound statement discussed above, the section goes on to imply
     that all "MSAs and MDAs can take advantage of having prior
     relationships", whereas that is only true for a subset of cases.
     In this case as well as the example noted above, it is likely that
     the "relationship" is not between MSA/MDA and "users", but is a
     contractual arrangement between some user and some administrative
     entity in the one case, and is a configuration item linking an
     MDA's operation to a mailbox (as defined in [R9.RFC2822]) in the
     other case.

   o The first bullet point at the end of draft section 3 uses the
     undefined term "submitting entity".  It is unclear whether that
     term refers to an SMTP client host, to a particular piece of
     software running on some host, to a responsible human user, or to
     some other entity.

   o That bullet point uses a BCP 14 imperative keyword, but no
     rationale or justification is given corresponding to the
     restrictions on usage for such imperatives as specified in section
     6 of BCP 14.

   o That bullet point also refers to "all mail submission mechanisms",
     and a subsequent part of the draft makes a nebulous reference to
     treating ordinary transfer "as mail submission".  Earlier draft
     text refers to software which incorporates multiple functions.  It
     is unclear precisely whether these are meant to be included in
     "all", or if "all" is being used carelessly.

   o The second bullet point uses awkward wording which is at best
     extremely difficult to parse.  It should be reworded to remove
     ambiguities so as to prevent likely incompatible interpretations.
     Specifically:

      * See above re. bizarre use of punctuation.

      * The term "received from" is undefined.  Does this refer to an IP
        address?  Something else?

      * "local operational environment" is extraordinarily vague.  What
        is the term supposed to mean?  The only constructive comment
        that can be made about such an extremely vague and poorly worded
        statement in a document intended for Standards Track or BCP is
        that its presence precludes reaching consensus agreement to the
        intended meaning of the specification in the document (since the
        intent is not communicated sufficiently clearly).

      * It fails to account for the difficulty in determining when
        "final delivery" takes place, as noted in [R10.RFC2821].

   o The third bullet point at the end of draft section 3 has problems
     of a similar nature and number:

      * "coming from" is undefined.  The lack of a definition is
        compounded by the similarity to, but distinct difference from,
        the earlier undefined term "received from".  One wonders not
        only what is meant by each of those terms, but what distinction
        is being made by the use of subtly different terms.

      * Likewise, "operator's local environment" is undefined and is
        similar to but distinct from the earlier undefined term "local
        operational environment".  The same concerns as immediately
        above also apply to this pair of undefined terms.

      * A BCP 14 imperative keyword is used with no rationale for such
        an imperative.

      * reference is made to transfer "treated as mail submission", but
        the meaning is unclear; does this refer to an implied permission
        to mangle message content?  To something else; if so
        specifically what is included and what is excluded?

      * The terms "authorization" and "validation" are used but are
        undefined by the draft (and no specific external reference is
        supplied) in that context.

      * It uses the term "RCPT-TO address" in a manner which is
        self-inconsistent (vs. "RCPT TO address" in section 4), is
        inconsistent with approved internet specifications (
        [R11.RFC821] and [R10.RFC2821]), both of which associate a
        "path" (not "address") with the RCPT TO (not hyphenated)
        command, and conflicts with other standard use of the term
        "address" (e.g. IP address, [R9.RFC2822] "address" (mailbox or
        named group)).

   o The last bullet point in draft section 3 also uses undefined terms,
     BCP 14 imperative keywords with no justification or rationale, and
     conflicts with current practice:

      * "recipients" is undefined.

      * "arrangement" is nebulous

      * no rationale for "SHALL NOT"

      * Some mail system operators provide a "catch-all" mailbox; the
        bullet point could be construed as prohibiting that current
        practice.

      * "delivery" is vague, especially in light of [R10.RFC2821] and
        forwarding, aliasing, list expansion, and the noted difficulty
        in determining when final delivery takes place.

   o The first sentence of the first paragraph of draft section 4 has a
     conflict between the words "desiring" and "need"; clearly either
     one term is too weak or the other is too strong.  The remainder of
     the paragraph is extraordinarily vague, and it is difficult to see
     how either a need or desire for end-to-end privacy is related to
     the hop-by-hop transfer implied by the draft text.  End-to-end
     privacy can be obtained with security multiparts as used by S/MIME
     and PGP/MIME, and are unrelated to transfer (except to the extent
     that transfer:

      * must not corrupt content, invalidating digital signatures

      * requires an end-to-end privacy mechanism to ensure privacy (i.e.
        if a transport intermediary is able to defeat security, there is
        no privacy)

      ).

   o The draft text makes an extremely brief reference to blocking of
     the SMTP well-known port number (25).  It claims that it "can be
     problematic for some users", but that is incorrect and
     irresponsibly understates the scope of the problem.  Blocking port
     25 precludes use of the SMTP VRFY command to determine the validity
     of a mailbox (e.g. [email-masked]).  With the ability to verify
     by a concise SMTP transaction blocked (N.B. none of RFC 2476, its
     draft successor, and/or the draft under discussion require support
     for VRFY in the "submission" protocol), it becomes necessary to
     transmit a full-blown message and hope for the best.  In the event
     of an invalid, expired, etc. mailbox, the typical result will be an
     additional delivery notification message which typically contains
     the entire original message plus transport markings plus plain text
     plus structured information regarding non-delivery, plus additional
     transport markings.  The resulting volume of (unnecessary if port
     25 is not blocked) traffic affects *all* users.  Port 25 blocking
     thus results in precisely the sort of situations for which use of
     BCP imperatives are intended, and the blocking and the harm which
     it causes should be proscribed by use of suitable BCP 14 text, e.g.
     "The well-known SMTP port MUST NOT be blocked".  It is
     irresponsible to misstate the scope of the problem caused by
     blocking ("some users") and to fail to address the problem by
     appropriate use of BCP 14 imperatives, especially as such
     imperatives are elsewhere used with no apparent justification.

   o Draft section 4 makes the (probably unintentionally) humorous claim
     that the draft document *uses* a particular TCP port.

   o The first bullet point at the end of draft section 4 is unclear
     because of:

      * Bizarre misuse of punctuation.

      * Unjustified use of BCP 14 imperative keywords (which conflicts
        with current practice).

      * The undefined term "support".  Does a server which always
        responds with a 421 greeting response code count as "support"?
        What about software that has a configurable option, but is
        operated with the option disabled?

      * The undefined term "local environment".

      * Direct conflict with approved Internet specifications RFC 2476
        and its draft successor, which both explicitly permit use  of
        the submission protocol on the well-known SMTP port (25).

   o The second bullet point in draft section 4:

      * Uses a BCP 14 imperative keyword with no rationale or
        justification

      * Does not define what or who is the object of "authentication",
        by what or whom, or on what basis or for what purpose.

      * Uses the term "RCPT TO address" in a manner which is
        self-inconsistent (vs. hyphenated "RCPT-TO address" in section
        3), is inconsistent with approved internet specifications
        ([R11.RFC821] and [R10.RFC2821]), both of which associate a
        "path" (not "address") with the RCPT TO command, and conflicts
        with other standard use of the term "address".

   o The third and last bullet points in draft section 4 presume that
     MSAs are in universal use, which is not currently true.  The last
     bullet point further presumes:

      * that there exists some MSA (as opposed to an MTA) operating on
        some host that can be used, and

      * that MUAs universally can be configured to use port 587, and

      * that somebody is able to perform the necessary configuration.

   o The figure in draft section 4 and the accompanying text refer to a
     "'home' MSA", which is nowhere defined.

   o The figure and text also presume the availability of a suitable MSA
     using port 587; both presumptions do not conform to universal
     current practice.

   o Draft section 5 conflates authentication and authorization.

   o Draft section 5 mentions POP-before-SMTP, which has known security
     defects and which therefore should not be encouraged; at minimum it
     should be strongly deprecated, ideally it would be prohibited with
     a corresponding BCP 14 imperative due to the security risks.

   o Draft section 5 fails to provide for authentication of an SMTP
     server to the connecting client, as discussed on the IETF
     discussion list regarding man-in-the-middle "evil twin" attacks.

   o In light of discussions on the IETF discussion list, the draft
     security considerations section is woefully inadequate.

   o The draft lacks the required IANA considerations section.

   o The normative references include:

      * RFC 821, which has been obsoleted according to the rfc-index and
        std-index

      * RFC 2476, which has Proposed Standard status

      * RFC 2821, which has Proposed Standard Status

      These may constitute improper downward references for a document
      intended as BCP.

   o BCP 14, a.k.a. RFC 2119, is improperly listed as an informative
     (rather than normative) reference.

   o Additional references may be required if external references are
     needed for terms which are presently undefined.

   o The Authors' Addresses section conflicts with the draft page one
     heading.

Please carefully review the references and resources indicated:

   [X] [R12.FYI36]

   [X] [R13.BCP22]

   [X] [R14.BCP26]

   [X] [R15.BCP61]

   [X] [R16.BCP72]

   [X] [R17.BCP97]

   [X] [R18.BCP104]

   [X] [R19.RFC1796]

   [X] [R20.RFC1925]

   [X] [R21.RFC1958]

   [X] [R22.RFC2223]

   [X] [R23.RFC3426]

   [X] [R24.RFC3439]

   [X] [R25.Errata]

The following applies to the document being reviewed:

   [X] The document needs substantial rework before serious review can
       take place.  In particular, substantive comment on any principles
       or practices which may have been intended is precluded at this
       time due to the extreme vagueness of the specification.  At least
       one additional broad community review cycle is desirable once the
       ambiguities, inconsistencies, etc. have been resolved.

References:

   [R1.Checklist] Wijnen, B., "Checklist for Internet-Drafts (IDs)
                  submitted for RFC publication", February 2005,
                  http://www.ietf.org/ID-Checklist.html

   [R2.ID]        Fenner, B., "Guidelines to Authors of
                  Internet-Drafts", March 2005,
                  ftp://ftp.ietf.org/ietf/1id-guidelines.txt

   [R3.Instruct]  Reynolds, J. and R. Braden, "Instructions to Request
                  for Comments (RFC) Authors"
                  (draft-rfc-editor-rfc2223bis-08.txt), July 2004.

   [R4.idnits]    http://ietf.levkowetz.com/tools/idnits/

   [R5.editor62]  RFC Editor, "Tutorial Slides",
                  ftp://ftp.rfc-editor.org/in-notes/rfc-editor/tutorial62.pdf

   [R6.BCP9]      Bradner, S., "The Internet Standards Process --
                  Revision 3", BCP 9, RFC 2026, October 1996.

   [R7.BCP14]     Bradner, S., "Key words for use in RFCs to Indicate
                  Requirement Levels", BCP 14, RFC 2119, March 1997.

   [R8.RFC822]    Crocker, D., "Standard for the format of ARPA Internet
                  text messages", STD 11, RFC 822, August 1982.

   [R9.RFC2822]   Resnick, P., "Internet Message Format", RFC 2822,
                  April 2001.

   [R10.RFC2821]  Klensin, J., "Simple Mail Transfer Protocol",
                  RFC 2821, April 2001.

   [R11.RFC821]   Postel, J., "Simple Mail Transfer Protocol", STD 10,
                  RFC 821, August 1982.

   [R12.FYI36]    Shirey, R., "Internet Security Glossary", RFC 2828,
                  May 2000.

   [R13.BCP22]    Scott, G., "Guide for Internet Standards Writers",
                  BCP 22, RFC 2360, June 1998.

   [R14.BCP26]    Narten, T. and H. Alvestrand, "Guidelines for Writing
                  an IANA Considerations Section in RFCs", BCP 26,
                  RFC 2434, October 1998.

   [R15.BCP61]    Schiller, J., "Strong Security Requirements for
                  Internet Engineering Task Force Standard Protocols",
                  BCP 61, RFC 3365, August 2002.

   [R16.BCP72]    Rescorla, E. and B. Korver, "Guidelines for Writing
                  RFC Text on Security Considerations", BCP 72,
                  RFC 3552, July 2003.

   [R17.BCP97]    Bush, R. and T. Narten, "Clarifying when Standards
                  Track Documents may Refer Normatively to Documents at
                  a Lower Level", BCP 97, RFC 3967, December 2004.

   [R18.BCP104]   Klensin, J., "Terminology for Describing Internet
                  Connectivity", BCP 104, RFC 4084, May 2005.

   [R19.RFC1796]  Huitema, C., Postel, J., and S. Crocker, "Not All RFCs
                  are Standards", RFC 1796, April 1995.

   [R20.RFC1925]  Callon, R., "The Twelve Networking Truths", RFC 1925,
                  April 1996.

   [R21.RFC1958]  Carpenter, B., "Architectural Principles of the
                  Internet", RFC 1958, June 1996.

   [R22.RFC2223]  Postel, J. and J. Reynolds, "Instructions to RFC
                  Authors", RFC 2223, October 1997.

   [R23.RFC3426]  Floyd, S., "General Architectural and Policy
                  Considerations", RFC 3426, November 2002.

   [R24.RFC3439]  Bush, R. and D. Meyer, "Some Internet Architectural
                  Guidelines and Philosophy", RFC 3439, December 2002.

   [R25.Errata]   RFC-Editor errata page,
                  http://www.rfc-editor.org/errata.html

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: request discussion of two documents on SMTP relaying
Date: Mon, 20 Jun 2005 13:22:45 -0400
Cc: Frank Ellermann <[email-masked]>, Keith Moore <[email-masked]>
Sender: [email-masked]

On Sun June 19 2005 02:01, Frank Ellermann wrote:
> 
> Keith Moore wrote:
[...]

> One MSA I know with millions of customers (mailto.t-online.de)
> even _sets_ the MAIL FROM and the 2822-From no matter what the
> MUA says.  One of the reasons why I've always supported you and
> Bruce when you say that "Reply-To" is strictly user territory -
> I just need it for this MSA.  Of course no 2476bis-MSA, option
> 6.1 does not cover to _set_ MAIL FROM, let alone the 2822-From.

1. Such MSAs (I know of one also) tend to be unusable precisely
   because of such message mangling (among other things, that
   improperly redirects delivery notifications from where the user
   expects them to go, and the message content mangling defeats
   privacy/security arrangements).  When coupled with brain-dead
   POP implementations for retrieval of (notification) messages,
   or worse, no retrieval mechanisms, such "services" are useless.

2. Reply-To won't help in such a case for delivery notifications,
   nor will it help if the recipient decides to "reply-to-author"
   (the From field holds the author(s) mailbox(es), by definition
   of the field).

> Normal users just don't care about it, they want to send mail,
> they want to get mail, they hate spam, they need "experts" to
> interpret a bounce, so it's our duty that they only get really
> relevant bounces, and not arbitrary forged "bounces to" crap.
> 
> > we need to stop trying to overload MAIL FROM, From, Sender,
> > etc to be the originator identity.   We need a new concept
> > for that.  Sender was close to the right idea

A new protocol is needed, or end-to-end solutions need to be
provided above SMTP.  SMTP simply has insufficient security to
do what you want (and some parts of SMTP (e.g. message mangling)
actively interfere with end-to-end privacy and authentication).

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: SMTP Mail Hosting and TMS Recommendations  [was: Hector's BCP summary outline for SMTP]
Date: Mon, 20 Jun 2005 13:10:09 -0400
Sender: [email-masked]

[while the half-baked scheme described isn't a draft, and therefore
is not under serious IETF consideration), it does warrant a brief
critique so that others do not make the same silly mistakes that the
author of this scheme has made.]

>    SMTP servers SHOULD publish an extended line 220 greeting response
>    indicating the system server basic mail policy.

1. The SMTP protocol is based on reply codes; text is meant for humans
   (RFC 2821 sections 4.2, 4.3).  The protocol is based solely on the
   reply codes, not on text.

2. Text in a dead language (e.g. Latin) is unlikely to be widely
   meaningful, nor is text in an obscure dialect of Chinese likely
   to be useful to a Swahili-speaking human (or vice versa) who happens
   to encounter non-protocol SMTP command text.

3. Policies may have legal ramifications, and some policies may be
   illegal is attempted to be applied to Internet traffic from some
   places.

4. Best Current Practice (specifically BCP 18) requires provision for
   internationalization of text.  SMTP has no such provision for text
   accompanying response codes.  Fortunately, such text is mostly
   optional and plays no role in the protocol.  Any attempt to
   superimpose some role on such text would run afoul of the BCP 18
   requirements.  Of course a new protocol could be defined differently,
   but that's another matter.

5. In particular, any extension to SMTP involving negotiation (e.g.
   of language for text) has to take place using the established ESMTP
   negotiation mechanism.  As that takes place after the greeting and
   EHLO stages, it cannot be used for negotiation affecting greetings,
   greeting reply codes or text, the EHLO command itself, its reply
   codes, or its reply text.  A properly-designed new protocol could
   address such matters, but again, that's not SMTP.

6. As SMTP has no provision for server authentication, the greeting
   (including text) can be trivially forged.

7. As noted in RFC 2821 section 3.1, information provided in greeting
   text may have security implications.

8. One might try to introduce additional reply codes for the greeting
   message to convey (in a language-independent and protocol-meaningful
   way) some nuances about a server administrator's policy.  But that
   would likely fail to interoperate with widely deployed client
   implementations which expect either a 220 or 251 greeting reply.
   Of course, a new protocol could address that, but then it wouldn't
   be SMTP.

> 1.2) HELO/EHLO
[...]
>    The SMTP server SHOULD perform SHOULD a Local Domain Network IP
>    validation check

Proofreading is always advisable...

[...]
>    Due to the nature of SMTP,  HELO/EHLO validation is relaxed and its
>    verification is weak.   There are legitimate reasons as to why a
>    client machine domain does not match the IP address.

So there are "legitimate reasons ..."  (agreed), but it SHOULD nevertheless
be checked.   Why?  And since (because of the "legitimate reasons") the
check provides no useful information, what is to be done with the results
of the "validation check"?

>    However, by SMTP 2821 requirements, the return path (MAIL FROM) MUST
>    be valid for potential system notification mail flows. A valid return
>    path is a fundamental and essential technical requirement for proper
>    mail flow,

A null reverse path is always valid.

>    Therefore, the SMTP server SHOULD highly consider to perform some
>    form of return path validation.  How this is done is a SMTP system
>    implementation dependent and considered as a "BLACK BOX"
>    concept and is subject to on going R&D.

No. It is known that some hare-brained schemes are harmful (e.g. issue
a test message using a server specified as an MX host for the MAIL FROM
domain (if not a null reverse path); hint: consider what happens if both
servers do that).  No "R&D" is needed to see that some schemes are
harmful.

From: "Hector Santos" <[email-masked]>
To: <[email-masked]>
Subject: Re: request discussion of two documents on SMTP relaying
Date: Mon, 20 Jun 2005 13:03:04 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

----- Original Message -----
From: "Keith Moore" <[email-masked]>
To: "Paul Smith" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Monday, June 20, 2005 11:16 AM
Subject: Re: request discussion of two documents on SMTP relaying

>
> > >You're missing important point. The reason lots of spam is coming from
> > >windows has a lot more to do with fundamental design flows in the OS
> > >that let to it be vulnerable to various forms of compromises and
takeover.
> >
> > Not really. It's that people use it who aren't security aware, and it's
a
> > popular OS, so it's targetted by attackers.
>
> The users are indeed part of the intertia that keep Windows insecure.

But are they the reason for the SMTP exploits?

Lets assumed the MS world was perfect and it didn't have all the security
issues,  would this eliminate or cut into the 60-80% of all malicious
transactions that begin with 100% exploitation of the SMTP weak points?

I think today, we understand that a compromised machine presents a different
set of issues that may not be related to Email authorization/authentication
R&D.

Anyway,  I don't think Windows insecurity issues are not related to the SMTP
problem that exist for all platforms.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

Date: Mon, 20 Jun 2005 11:16:57 -0400
From: Keith Moore <[email-masked]>
To: Paul Smith <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: request discussion of two documents on SMTP relaying
Sender: [email-masked]

> >You're missing important point. The reason lots of spam is coming from
> >windows has a lot more to do with fundamental design flows in the OS
> >that let to it be vulnerable to various forms of compromises and takeover.
> 
> Not really. It's that people use it who aren't security aware, and it's a 
> popular OS, so it's targetted by attackers.

The users are indeed part of the intertia that keep Windows insecure.
So are the people who write code for Windows boxes who ask users to do
things to make their computers less secure.   But MS has also
contributed to this problem by (for many years) deliberately making
their mail readers and web browsers less secure than permitted by the
MIME specification, by encouraging users to operate their systems in a 
less-secure-than-necessary manner by giving them inflexible security
settings in email readers and browsers, by making various choices to
favor insecurity in their operating system on the belief that it would
increase their market share, and (until recently) by failing to
carefully examine all of their servers and applications with an eye to
security.

In a nutshell: MS started off with an insecure OS (DOS), then added TCP
support in Windows 95 without doing anything to make the system more
secure against attack from the network, then started shipping mail
readers and web browsers that violated the MIME specification's
security rules, while meanwhile providing more and more insecure
network servers, some of which were enabled by default.  By the time
they started to realize the error of their ways, the tremendous inertia
of the installed base - which includes not only the large number of old
versions of software being run but also the expectations of users and
code developers -have made it difficult to change things.

Of course, some of these mistakes were also made by other OS vendors.
But MS's huge installed base (resulting in part from various illegal
efforts to maintain their monopoly) has meant that any mistakes made by
MS were amplified.  That, and whereas the UNIX community got agressive
about trying to find bugs in server software after the Morris worm
alerted the UNIX community to the problems associated with network
attack, MS kept their heads in the sand about it for another ten or so
years.

Keith

From: "Hector Santos" <[email-masked]>
To: "Keith Moore" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: request discussion of two documents on SMTP relaying
Date: Mon, 20 Jun 2005 09:44:57 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

----- Original Message -----
From: "Keith Moore" <[email-masked]>

> > From my standpoint 2476 "legalized" the strong authentication
requirement
> > that removed all user privacy rights.
>
> I believe this needs to be revisited, as the ability to send anonymous
> mail is socially valuable.  Recipients need to be able to block
> anonymous mail if they wish to do so, but the MTS should not block it
> for them.

Would it be useful to define what "anonymous" means?   How much
accountability applies?  How much tracing is enough?    It is verifible?

> > But if ESMTP AUTH or IP relay checking is enforced for ISP
> > users, then port 587 is a mute point.
>
> No it's not, first because source IP address checking and many forms of
> SMTP AUTH are broken for reasons mentioned earlier;
> second because it's not reasonable to assume that either all
> transactions from a particular IP address are submissions or all of
> them are relays.  Submission is (or should be) a different operation than
> relaying in many respects, and it's important that there be a clear
> indication of which operation is being requested.

I agree, took me a while to put all the tangents in context to see what you
mean. :-)

I guess I can only speak for how our server is design and how it fits and
works with other standard mail servers.

Usually this is determined at the RCPT TO state.  I mean the RCPT TO state
usually defines the personality of the receiving MTA server (RMTA) and the
level of security required.

My point above regarding Port 587 was in regards to "allowing" routing,  you
typically have a implicit or explicit set of rules or requirements.  If a
route requirement is already satisfied than the implicity port 587 usage is
a mute point.

In my view, at the top level, ESMTP AUTH vs 2476 is basically a "Explicit
vs. Implicit" authorization concept similar to FTP Implicit and Explicit
SSL.

Implicit uses a specific port with an implied security level defined
requirement. The MTA has no choice.  Security is presumed.

Explicit uses the standard port with an optional security level defined. The
MTA has a choice to use ESMTP AUTH or not.  If he doesn't, then only local
mail is allowed.  The Receiver MTA is essentially a MDA.

2476 is basically implicit ESMTP AUTH.  Yes, 2476 imposes other things too,
like 2822 checking and/or modification/setting concepts and I think this is
where we are at as it relates to user privacy or anonymity and also now,
possibly helping to address transition points for LMAP based protocols (SPF,
SENDERID).

In my interpretation,  Implicit ESMTP AUTH (2874) legalizes the 2822
analysis and changes if necessary.  Currently it removes all user privacy if
the MSA enforces Sender, etc.   Explicit ESMTP AUTH does not  as it only
currently uses for routing purposes.

But in both cases when it comes to routing, they both satisfy one of the
authorization requirements needed for routing.

Again, I am describing how our system is currently is designed and place to
interoperate with other similar systems. I think to think it is following
the BCP to the highest degree.

Above all,  backward compatibility is paramount and when you reduce it down
to what means it to make it backward compatible it boils down to:

     Local Mail --> No authorization required  (the MTA is now a MDA)
     Remote Mail -->  Authorization required  (the MTA is now a MSA)

The issues with LMAP protocols, SPF/SENDERID for the most part,  these are
protocols that are designed to fit into the current model with hopefully the
highest regard to backward compatibility with the hope for the highest form
of easy adoption and acceptance.

The problem?

The transition points, the routing points where the originating IP and
originating domain association (IP::DOMAIN) is no longer intact.

The proposed solutions are:

    SUBMITTER (2821)
    SENDERID (2822, PAYLOAD)
    SRS (2821)

SUBMITTER addresses the persistent nature of MAIL FROM so that when the mail
reaches its final destination point, the IP::DOMAIN association may not be
intact in a multi-hop path.    So SUBMITTER is used as an ESMTP Mail From
keyword modifier:

    MAIL FROM <address> SUBMITTER=original_address

This has a privacy problem.  My change recommendation was to use only the
domain since SPF only needs the domain to validate the IP::DOMAIN
association.

SENDERID addresses the problem when the MTA is not SUBMITTER compliant and
when use the payload to check the 2822 headers for the originating address.

This is where 2476 comes into play where it could add the SENDER: header to
assist the downlink MDA SenderID ready server.

Again, this presents a privacy issue.  A suggestion is to add a new header:

        SENDER-DOMAIN:

for SPF lookup purposes.

and finally, SRS modifies the return path (MAIL FROM) so that it is
consistent with the IP::DOMAIN at the final destination.   I don't think SRS
raises a privacy problem, but in general I don't like the idea of modifying
the MAIL FROM.

So when you put it all together,  we are really still at square one because
we still need to have backward compatible explicitly support for anonymous
transactions.

The question is then, what is anonymous transactions? and what can be done
for the legacy client who may not be using any of the new stuff?

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

Date: Mon, 20 Jun 2005 11:32:18 +0100
To: Arnt Gulbrandsen <[email-masked]>, [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: request discussion of two documents on SMTP relaying
Cc: Keith Moore <[email-masked]>
Sender: [email-masked]

At 11:09 20/06/2005, Arnt Gulbrandsen wrote:
>Paul Smith writes:
>>At 11:02 19/06/2005, Arnt Gulbrandsen wrote:
>>>About 40-50% of the reviewed games require that. Now, isn't that ridiculous?
>>
>>Yes - but that's not Windows fault, or Microsoft's fault... It's the 
>>fault of the people who write the games software, and the users who 
>>accept that state. Because 50-60% of the reviewed games DON'T require 
>>administrator rights to play, it shows that it's not an OS problem, as 
>>those 50-60% of game developers have been able to done the job right with 
>>the same OS as those who haven't bothered.
>
>Back when I wrote libraries for a living, if only 50-60% of my customers 
>were able to use the API without serious problems, I wouldn't say «oh, our 
>API is correct, half the API's users are in the wrong». I would look for 
>the the root cause in _our_ code or API. I'd talk to customers and ask 
>«what is it about the API that has led so many developers down the wrong 
>path?» (From experience, I can tell you that it's usually easy to find the 
>answer, but solving the problem without breaking compatibility can be tricky).
>
>So, yes I think it's Microsoft's fault.

Most of the problems are often simply a case of requiring write permission 
to the system directories, or needing write permission to certain parts of 
the registry. It's not an API issue. It's like a Linux game needing to be 
able to write to the /sbin directory - if a game did that you wouldn't say 
that it was a problem with the Linux API, but many Windows games do require 
write permission to the \Windows\System folder for some odd reason, or to 
the system parts of the registry, or whatever. Microsoft tell people not to 
do this, but they do it anyway - the only way Microsoft could improve 
things is for all software to be 'approved' by Microsoft before it was 
released... It's trivial to do it properly, but many independent developers 
don't care - they write and test in admin mode themselves.

Paul                            VPOP3 - Internet Email Server/Gateway
[email-masked]                      http://www.pscs.co.uk/

Date: Mon, 20 Jun 2005 10:26:21 +0100
To: "william(at)elan.net" <[email-masked]>
From: Paul Smith <[email-masked]>
Subject: Re: request discussion of two documents on SMTP relaying
Cc: IETF-SMTP <[email-masked]>
Sender: [email-masked]

At 21:51 18/06/2005, you wrote:

>On Sat, 18 Jun 2005, Paul Smith wrote:
>>
>>On Sat, 18 Jun 2005 17:55:25 +0100, Keith Moore <[email-masked]> wrote:
>>>I'd even go so far as to say we're going to continue to have massive 
>>>amounts of spam as long as Windows is the dominant PC operating system.
>>
>>I'm sorry, but that's just ridiculous. The only link between Windows and
>>spam is that lots of people have Windows, and it's relatively easy to use,
>
>You're missing important point. The reason lots of spam is coming from
>windows has a lot more to do with fundamental design flows in the OS
>that let to it be vulnerable to various forms of compromises and takeover.

Not really. It's that people use it who aren't security aware, and it's a 
popular OS, so it's targetted by attackers.

There are security vulnerabilities in Macs, Linux etc as well. They're just 
less popular OSes so they're less targetted by attackers.

There's nothing stopping anyone writing a trojan for Linux which will act 
just the same as many trojans for Windows - eg mass mailers that spread 
themselves as email worms and then allow the PCs to be used for mailing out 
spam. But, no one bothers, because (a) there are less Linux PCs out there, 
and (b) Linux users tend to be more security aware than Windows users, so 
an attack like this is less likely to work.

If you say 'ban Windows, it's insecure', you'll just move the problem over 
to a different platform. The security issues will tend towards the platform 
where the least security aware people are. At the moment this is Windows - 
but this isn't necessarily because it's that insecure than the other 
platforms, just that the USERS are more "insecure". If you could force all 
the Windows users to use Linux, for instance, you'd most likely find that 
Linux would then be seen as the 'insecure' platform (eg a large number of 
users would run Linux as 'root' with a password 'of 'password' or '12345' 
etc). This isn't a problem caused by the OS, but by the users that use it.

>If what you said was right then proportions of non-spammer use of
>windows vs linux would be the same or clos to te spammer use.

Not really - see my argument above. *Currently* most Linux users are 
security aware, and most Windows users aren't, so attackers will target 
Windows PCs. If you're going to write an email worm/trojan, you'd obviously 
prefer to write one which could attack 1 billion PCs where only 50% of them 
will have working security protection, rather than one which could attack 
100,000 PCs where 95% of them are protected. (The numbers are totally made 
up just as an example, but you get my point).

Paul                            VPOP3 - Internet Email Server/Gateway
[email-masked]                      http://www.pscs.co.uk/

Date: Mon, 20 Jun 2005 12:09:49 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: request discussion of two documents on SMTP relaying
Cc: Keith Moore <[email-masked]>, Paul Smith <[email-masked]>
Sender: [email-masked]

Paul Smith writes:
> At 11:02 19/06/2005, Arnt Gulbrandsen wrote:
>> About 40-50% of the reviewed games require that. Now, isn't that ridiculous?
>
> Yes - but that's not Windows fault, or Microsoft's fault... It's the 
> fault of the people who write the games software, and the users who 
> accept that state. Because 50-60% of the reviewed games DON'T require 
> administrator rights to play, it shows that it's not an OS problem, 
> as those 50-60% of game developers have been able to done the job 
> right with the same OS as those who haven't bothered.

Back when I wrote libraries for a living, if only 50-60% of my customers 
were able to use the API without serious problems, I wouldn't say «oh, 
our API is correct, half the API's users are in the wrong». I would 
look for the the root cause in _our_ code or API. I'd talk to customers 
and ask «what is it about the API that has led so many developers down 
the wrong path?» (From experience, I can tell you that it's usually 
easy to find the answer, but solving the problem without breaking 
compatibility can be tricky).

So, yes I think it's Microsoft's fault.

> I could easily write a Linux game which requires you to be logged in 
> as root to play it. That wouldn't be Mr Torvald's fault.

Agreed. But if Linus did such a poor job that half the game developers 
chose to do that, most of the blame would be his.

This is my last post on this topic; it's not about IETF or SMTP any 
more. I will say, though, that we all have a moral responsibility for 
fixing any aspects of our protocols or software that lead half of _our_ 
customers to do stupid, wrong or harmful things.

Arnt

Date: Mon, 20 Jun 2005 10:26:26 +0100
To: Arnt Gulbrandsen <[email-masked]>, [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: request discussion of two documents on SMTP relaying
Cc: Keith Moore <[email-masked]>
Sender: [email-masked]

At 11:02 19/06/2005, Arnt Gulbrandsen wrote:
>Paul Smith writes:
>>On Sat, 18 Jun 2005 17:55:25 +0100, Keith Moore <[email-masked]> wrote:
>>>I'd even go so far as to say we're going to continue to have massive
>>>amounts of spam as long as Windows is the dominant PC operating system.
>>
>>I'm sorry, but that's just ridiculous. The only link between Windows and 
>>spam is that lots of people have Windows, and it's relatively easy to 
>>use, so lots of spammers use it. Lots of spammers also use Linux or Macs, 
>>you just see less of that, because there are less of those systems in use 
>>by the 'spammer' sort of person, but if that's all there was, that's what 
>>the spammers would use.
>
>Easy to use, you say.
>
>I read a computer magazine called c't. High-quality thing. For example, 
>when it reviews Windows games, the review specifically notes whether the 
>game requires administrator rights to play. (Not to install. To play.)
>
>About 40-50% of the reviewed games require that. Now, isn't that ridiculous?

Yes - but that's not Windows fault, or Microsoft's fault... It's the fault 
of the people who write the games software, and the users who accept that 
state. Because 50-60% of the reviewed games DON'T require administrator 
rights to play, it shows that it's not an OS problem, as those 50-60% of 
game developers have been able to done the job right with the same OS as 
those who haven't bothered.

I could easily write a Linux game which requires you to be logged in as 
root to play it. That wouldn't be Mr Torvald's fault. However, if I did 
write such a game, I wouldn't expect to sell many copies because Linux 
users tend to be more security aware than Windows users.

>I bet that if Microsoft ever changes Windows such that people don't 
>routinely run their day-to-day applications as Administrator, Windows will 
>also be less "easy to use" for spammers.

Agreed - but whether that's Microsoft's fault or the application developers 
faults is debateable.

Paul                            VPOP3 - Internet Email Server/Gateway
[email-masked]                      http://www.pscs.co.uk/

Date: Sun, 19 Jun 2005 16:08:23 -0400
From: Keith Moore <[email-masked]>
To: Frank Ellermann <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: user interface problems (was Re: request discussion of two documents on SMTP relaying)
Sender: [email-masked]

> Today's users want
> something working like a TV, "PnP", not a hobby where
> a university degree helps to get started.
> 
> And to say something on topic, it's "our" job to give
> them a really "simple mail transfer protocol".  It's
> their right to think that a "mail header" is "black
> magic", and to refuse to read tons of RfCs and FAQs.
> 
> If you're an "expert" asked about this, and you start
> with "well, all of this forged anyway", you lose.  It
> doesn't help if you then try to explain "bounces to",
> IPs, or anonymous mail.  Bye, Frank

I don't disagree with you.  But somehow users have managed to
understand several similar concepts in the world of snail mail.  

Most people can grasp how a forger can print his own letterhead, 
print a message onto it, and fake a signature at the bottom - why 
can't they understand that similar things are possible in email?   

Most people could look at a letter and notice whether the signature
at the bottom of the letter had the same name as the "from" address
in the heading of the letter.

Most people understand that when the postal service decides to return a
message it's going to return it to the address on the outside of the
envelope, and when you send a reply you're going to send it to the
address in the letter itself.

Granted there are some things that are hard to understand about
digital signatures - like the notion of a certificate chain.  But I think
most of these things could be made clear with well-designed user
interfaces.

Keith

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: request discussion of two documents on SMTP relaying
Date:  Sun, 19 Jun 2005 21:37:53 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 26
Sender: [email-masked]

Arnt Gulbrandsen wrote:
 
> I read a computer magazine called c't.

Oops, me too, less frequently now, because I'm not that
interested in Win-topics...

> the degree to which it currently dominates surely is
> connected to its _bad_ _bad_ security.

...their security update procedures are rather nice.

It all also depends on the users.  Today's users want
something working like a TV, "PnP", not a hobby where
a university degree helps to get started.

And to say something on topic, it's "our" job to give
them a really "simple mail transfer protocol".  It's
their right to think that a "mail header" is "black
magic", and to refuse to read tons of RfCs and FAQs.

If you're an "expert" asked about this, and you start
with "well, all of this forged anyway", you lose.  It
doesn't help if you then try to explain "bounces to",
IPs, or anonymous mail.  Bye, Frank

Date: Sun, 19 Jun 2005 08:16:31 -0700
To: Arnt Gulbrandsen <[email-masked]>, [email-masked]
From: David MacQuigg <[email-masked]>
Subject: Solution to Windows Email Zombie Problem
Cc: Keith Moore <[email-masked]>, Paul Smith <[email-masked]>
Sender: [email-masked]

At 12:02 PM 6/19/2005 +0200, Arnt Gulbrandsen wrote:
>Paul Smith writes:
>>On Sat, 18 Jun 2005 17:55:25 +0100, Keith Moore <[email-masked]> wrote:
>>>I'd even go so far as to say we're going to continue to have massive
>>>amounts of spam as long as Windows is the dominant PC operating system.
>>
>>I'm sorry, but that's just ridiculous. The only link between Windows and 
>>spam is that lots of people have Windows, and it's relatively easy to 
>>use, so lots of spammers use it. Lots of spammers also use Linux or Macs, 
>>you just see less of that, because there are less of those systems in use 
>>by the 'spammer' sort of person, but if that's all there was, that's what 
>>the spammers would use.
>
>Easy to use, you say.
>
>I read a computer magazine called c't. High-quality thing. For example, 
>when it reviews Windows games, the review specifically notes whether the 
>game requires administrator rights to play. (Not to install. To play.)
>
>About 40-50% of the reviewed games require that. Now, isn't that ridiculous?
>
>I bet that if Microsoft ever changes Windows such that people don't 
>routinely run their day-to-day applications as Administrator, Windows will 
>also be less "easy to use" for spammers.
>
>>That comment is like saying 'If Ford stopped making cars, there'd be 
>>less  car accidents'.
>>
>>The operating system is irrelevant. Don't try to turn this into a 'Gates 
>>is a bad guy' argument!.. Whether he is or not is irrelevant to the 
>>spamming issue!
>
>A less trojan-friendly Windows may still be the dominant spammer OS, but 
>the degree to which it currently dominates surely is connected to its 
>_bad_ _bad_ security.

I have also heard that M$ is unwilling to make its security updates 
available to unlicensed systems, which probably includes most of the 
zombies.  My guess is they are trying to turn this PR disaster into a win 
by timing the zombie shutdown so the credit for saving the email system 
goes to SenderID.

Seems like someone should develop an open-source "anti-zombie" program that 
could be used by ISPs to neuter their zombies.  Any user system that is 
open for spammers would also be open for a benign patch.  "Sorry, your mail 
has been blocked, because your system has been infected with a mail 
worm.  <Click Here> to install a patch on your system and re-activate your 
account."  Of course, there would need to be some user education follow on, 
and stricter measures if it happens again.

--
Dave
************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at yahoo.com     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *

Date: Sun, 19 Jun 2005 12:02:40 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: request discussion of two documents on SMTP relaying
Cc: Keith Moore <[email-masked]>, Paul Smith <[email-masked]>
Sender: [email-masked]

Paul Smith writes:
> On Sat, 18 Jun 2005 17:55:25 +0100, Keith Moore <[email-masked]> wrote:
>> I'd even go so far as to say we're going to continue to have massive  
>> amounts of spam as long as Windows is the dominant PC operating 
>> system.
>
> I'm sorry, but that's just ridiculous. The only link between Windows 
> and spam is that lots of people have Windows, and it's relatively 
> easy to use, so lots of spammers use it. Lots of spammers also use 
> Linux or Macs, you just see less of that, because there are less of 
> those systems in use by the 'spammer' sort of person, but if that's 
> all there was, that's what the spammers would use.

Easy to use, you say.

I read a computer magazine called c't. High-quality thing. For example, 
when it reviews Windows games, the review specifically notes whether 
the game requires administrator rights to play. (Not to install. To 
play.)

About 40-50% of the reviewed games require that. Now, isn't that ridiculous?

I bet that if Microsoft ever changes Windows such that people don't 
routinely run their day-to-day applications as Administrator, Windows 
will also be less "easy to use" for spammers.

> That comment is like saying 'If Ford stopped making cars, there'd be 
> less  car accidents'.
>
> The operating system is irrelevant. Don't try to turn this into a 
> 'Gates is a bad guy' argument!.. Whether he is or not is irrelevant 
> to the spamming issue!

A less trojan-friendly Windows may still be the dominant spammer OS, but 
the degree to which it currently dominates surely is connected to its 
_bad_ _bad_ security.

Arnt

Date: Sun, 19 Jun 2005 03:25:34 -0400
From: Keith Moore <[email-masked]>
To: Frank Ellermann <[email-masked]>
Cc: [email-masked]
Subject: Re: request discussion of two documents on SMTP relaying
Sender: [email-masked]

>>in mail submission the client is the originator, in mail
>>relaying the client is just a random MTA.  so authentication
>>means different things in the two cases.
> 
> Yes.  For the latter MTAMARK, CSV, or the HELO-part of SPF can
> do the trick (add SIQ and it shouldn't be too expensive).

I was referring to client-to-server authentication, not 
originator-to-server authentication.

>>eventually I think we need a way for originators to
>>demonstrate that they have permission to use a particular
>>MAIL FROM, but this requires protocol extensions
> 
> 
> Depends.  MSAa offered by ISPs or mail providers normally know
> which mailbox(es) an authorized user has, for SMTP-after-POP
> it's more or less obvious.

yes, but there are legitimate reasons for not using the MSA offered by 
the mail network where you receive your mail, and there are also 
legitimate reasons for setting MAIL FROM to something other than the 
address at which you normally receive mail.

> Based on that knowledge they can "enforce submission rights".

yes they can, but it's not something we should encourage.

> One MSA I know with millions of customers (mailto.t-online.de)
> even _sets_ the MAIL FROM and the 2822-From no matter what the
> MUA says.

that's just broken.

> And for SMTP-after-POP "enforcing submission rights" closes the
> window of an "enabled" IP ready to relay for everybody who has
> the IP.  

it doesn't solve the problem of spoofing.  SMTP-after-POP is easy for an 
man-in-the-middle attack to break.  the attacker intercepts the traffic 
between the MUA and the POP server, using its own IP address to talk to 
the POP server, then it can submit mail from the same IP address at 
will.  SMTP-after-POP should be a SHOULD NOT or NOT RECOMMENDED just 
like AUTH PLAIN and AUTH LOGIN and CRAM-MD5 and APOP, because it's 
defeated just as easily.

>>we'd like to get something less ambitious out the door sooner
>>than that.
> 
> 
> It's not that ambitious for ordinary users of the big ISPs.  If
> the ISP is say AOL the user has an address @aol.  While we all
> hate to mess with mail headers - trying to fix it makes it often
> worse, everybody learned that lesson -  it's no big problem to
> check and enforce a proper MAIL FROM.  

yes, it's easy to do.  it's also wrong.

> Normal users just don't care about it, they want to send mail,
> they want to get mail, they hate spam, they need "experts" to
> interpret a bounce, so it's our duty that they only get really
> relevant bounces, and not arbitrary forged "bounces to" crap.

users have a wide range of needs.  it's not acceptable to limit all 
users to what you think "normal" users need.  and this won't solve the 
spam problem anyway, not by a long shot.

I'm all for having a way for MTAs to insist that the originator had 
permission to use that MAIL FROM address to send the message.  What's 
not acceptable is for SMTP or MSA to decide this solely on the basis of 
SMTP AUTH credentials or source IP address.

> 
>>we need to stop trying to overload MAIL FROM, From, Sender,
>>etc to be the originator identity.   We need a new concept
>>for that.  Sender was close to the right idea
> 
> 
> Yes, and MAIL FROM used to be a copy of this Sender. 

no.  MAIL FROM has always been where bounces go.  It was often, but not 
always, the same as Sender.  In the case of mailing lists Sender should 
be the original originator (so the list members will know who really 
sent the message) and MAIL FROM should point to an address that will 
accept bounces from the list.

> In your
> MON-terminology it's an internal business of each MON how they
> organize it, as far as I'm concerned they can use BATV, SES,
> secy@MON, secy-daemon@MON, anon@MON, user@MON, crypto-id@MON,
> or whatever they like, but not [email-masked] for
> any MON != claranet.de.

maybe the owner of a domain has the right to say who can use addresses 
from that domain - that makes some sense to me.  but a MON should not 
have to be associated with a domain.  users of an email address have 
legitimate needs to be able to submit mail through other MONs.  so SMTP 
AUTH isn't the right way to establish whether a user can use a 
particular domain.  there are cases where it is sufficient, but it's not 
sufficient in general.

> So I don't see any need for a _new_ concept, we need the _old_
> STD 10 concept, and that's what the RMX-part of SPF does.

anything that tries to tie domains to source-IP addresses is hopelessly 
broken.  we should make this a MUST NOT, or at least a SHOULD NOT.

Keith

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: request discussion of two documents on SMTP relaying
Date:  Sun, 19 Jun 2005 08:01:20 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 73
Cc: Keith Moore <[email-masked]>
Sender: [email-masked]

Keith Moore wrote:

> in mail submission the client is the originator, in mail
> relaying the client is just a random MTA.  so authentication
> means different things in the two cases.

Yes.  For the latter MTAMARK, CSV, or the HELO-part of SPF can
do the trick (add SIQ and it shouldn't be too expensive).

> eventually I think we need a way for originators to
> demonstrate that they have permission to use a particular
> MAIL FROM, but this requires protocol extensions

Depends.  MSAa offered by ISPs or mail providers normally know
which mailbox(es) an authorized user has, for SMTP-after-POP
it's more or less obvious.  Not that I'm a fan of this scheme,
but removing POP from the equation won't change the knowledge.

Based on that knowledge they can "enforce submission rights".

One MSA I know with millions of customers (mailto.t-online.de)
even _sets_ the MAIL FROM and the 2822-From no matter what the
MUA says.  One of the reasons why I've always supported you and
Bruce when you say that "Reply-To" is strictly user territory -
I just need it for this MSA.  Of course no 2476bis-MSA, option
6.1 does not cover to _set_ MAIL FROM, let alone the 2822-From.

They just do it anyway, and those who don't like it can get a
premium account on another MSA.

And for SMTP-after-POP "enforcing submission rights" closes the
window of an "enabled" IP ready to relay for everybody who has
the IP.  Hector's one minute window is probably short enough,
so he doesn't need 2476 to close it.

> we'd like to get something less ambitious out the door sooner
> than that.

It's not that ambitious for ordinary users of the big ISPs.  If
the ISP is say AOL the user has an address @aol.  While we all
hate to mess with mail headers - trying to fix it makes it often
worse, everybody learned that lesson -  it's no big problem to
check and enforce a proper MAIL FROM.  Or even _set_ it after
discussing it with the legal department, the privacy officer,
and ideally the user.

Normal users just don't care about it, they want to send mail,
they want to get mail, they hate spam, they need "experts" to
interpret a bounce, so it's our duty that they only get really
relevant bounces, and not arbitrary forged "bounces to" crap.

> we need to stop trying to overload MAIL FROM, From, Sender,
> etc to be the originator identity.   We need a new concept
> for that.  Sender was close to the right idea

Yes, and MAIL FROM used to be a copy of this Sender.  In your
MON-terminology it's an internal business of each MON how they
organize it, as far as I'm concerned they can use BATV, SES,
secy@MON, secy-daemon@MON, anon@MON, user@MON, crypto-id@MON,
or whatever they like, but not [email-masked] for
any MON != claranet.de.

So I don't see any need for a _new_ concept, we need the _old_
STD 10 concept, and that's what the RMX-part of SPF does.  With
any freedom you like, from not participating at all, aggregate
MONs, or only exclude MONs (e.g exclude IPs listed by SPEWS if
that's what you want).

> it's probably not a good idea to assume that the originator
> ID is an email address.

If 64 base64 characters are enough just add @MON as RHS.  Bye

Date: Sat, 18 Jun 2005 17:32:19 -0400
From: Keith Moore <[email-masked]>
To: Dave Crocker <[email-masked]>
Cc: IETF-SMTP <[email-masked]>
Subject: Re: request discussion of two documents on SMTP relaying
Sender: [email-masked]

Dave Crocker wrote:
>> I think we need a whole set of what I think
>> of as "operational recommendations for email" (ORE would be a good
>> acronym) to improve interoperability between mail clients and mail
>> networks, and also to improve security, make the mail system more
> 
> 
> I entirely agree.
> 
> The way to achieve that is through incremental specification of best practises 
> (or modified technical specifications).
> 
> If we require solving the entire set of problems before we publish any portion 
> of the improvements, nothing will get published.

Agree.  And I think the current bit of scope related to submission and 
relaying between mail networks is a good place to start.

Keith

Date: Sat, 18 Jun 2005 17:29:52 -0400
From: Keith Moore <[email-masked]>
To: Frank Ellermann <[email-masked]>
Cc: [email-masked]
Subject: Re: request discussion of two documents on SMTP relaying
Sender: [email-masked]

>>I'm not sure what context is describe in which "hector" will
>>comment about this.   Our server is a complete MSA/MTA/MDA
>>system
> 
> Yes, that's the point.  Keith apparently envisions a system
> where the functions MTA (incl. MX) and MSA are separated, so
> you can always say "this box follows 2476 rules" (= MSA) and
> "this other box follows 2821 rules" (= MTA).

Well, mail submission and relaying are subtly different operations, and 
they do need to be treated differently even if they're implemented by 
the same code (with occasional if (role==MSA) { ... } else { ... }
constructs).  For instance:

- in mail submission it's some desirable to modify a message under some 
circumstances (say to add a missing Date field), whereas a mail relay 
should preserve the message with as few changes as possible
- in mail submission the client is the originator, in mail relaying the 
client is just a random MTA.  so authentication means different things 
in the two cases.
- the rules for accepting mail are different for submission than for 
relaying between mail networks

That's not to say that MSA and MTA have to be separate "boxes" - but we 
shouldn't treat them as if they're the same function.

> 
> And the "2821-rules" include stuff like "don't mess with the
> mail header" (excl. trace header fields for the moment).

or for that matter the message body (modulo 8-to-7 bit conversion)

>>Since authorization is a prearrange relationship, return path
>>validation overhead is deemed unnecessary.
> 
> 
> If an authorized user can still use any MAIL FROM he likes
> you're in trouble as soon as one of your users is a zombie.

eventually I think we need a way for originators to demonstrate that 
they have permission to use a particular MAIL FROM, but this requires 
protocol extensions will take a while to iron out, and we'd like to get 
something less ambitious out the door sooner than that.

also (and this is a separate issue) we need to stop trying to overload 
MAIL FROM, From, Sender, etc to be the originator identity.   We need a 
new concept for that.  Sender was close to the right idea but it's been 
too widely abused to fix, also it's probably not a good idea to assume 
that the originator ID is an email address.

Keith

Date: Sat, 18 Jun 2005 17:01:21 -0400
From: Keith Moore <[email-masked]>
To: Paul Smith <[email-masked]>
Cc: IETF-SMTP <[email-masked]>
Subject: Windows security (was Re: request discussion of two documents on SMTP relaying)
Sender: [email-masked]

> On Sat, 18 Jun 2005 17:55:25 +0100, Keith Moore <[email-masked]> wrote:
> 
>> I'd even go so far as to say we're going to continue to have massive  
>> amounts of spam as long as Windows is the dominant PC operating system.
> 
> 
> I'm sorry, but that's just ridiculous. The only link between Windows and
> spam is that lots of people have Windows, and it's relatively easy to use,
> so lots of spammers use it.

Well, Windows does have a well-deserved reputation for being easy to 
break into, and a lot of spam these days comes from compromised Windows 
hosts.  Much of this reputation results from deliberate decisions on the 
part of MS to violate the MIME specifications - in particular, to allow 
the sender of a message to effectively be able to specify what 
application will be used to run a message (by specifying the filename 
extension) and to allow untrustworthy content to be presented (by 
running that application) rather than simply offering to save the 
content to a file.  Maybe they've fixed this by now.  I wouldn't know 
because I stopped using Windows several years ago.

In addition, Windows has some fairly deep assumptions about what a 
program ought to be able to do with (to?) a computer that make it less 
secure than other OSes.  So yes, IMHO there are limitations to the 
security of Windows that are not shared by all other OSes, and the only 
way to fix that problem is for Windows to drastically break 
compatibility with previous versions of Windows.

So while there might be a bit of exaggeration to my statement, in the 
sense that it's possible to make an OS that's called "Windows" that is 
as secure as any other OS (as long as you don't care to make it terribly 
backward compatible), I think it's as correct as any one-sentence 
generalization about spam can be.

Keith

Date: Sat, 18 Jun 2005 13:51:47 -0700 (PDT)
From: "william(at)elan.net" <[email-masked]>
To: Paul Smith <[email-masked]>
cc: Keith Moore <[email-masked]>, IETF-SMTP <[email-masked]>
Subject: Re: request discussion of two documents on SMTP relaying
Sender: [email-masked]

On Sat, 18 Jun 2005, Paul Smith wrote:
>
> On Sat, 18 Jun 2005 17:55:25 +0100, Keith Moore <[email-masked]> wrote:
>> I'd even go so far as to say we're going to continue to have massive 
>> amounts of spam as long as Windows is the dominant PC operating system.
>
> I'm sorry, but that's just ridiculous. The only link between Windows and
> spam is that lots of people have Windows, and it's relatively easy to use,

You're missing important point. The reason lots of spam is coming from
windows has a lot more to do with fundamental design flows in the OS
that let to it be vulnerable to various forms of compromises and takeover.

> The operating system is irrelevant. Don't try to turn this into a
> 'Gates is a bad guy' argument!.. Whether he is or not is irrelevant
> to the spamming issue!

If what you said was right then proportions of non-spammer use of
windows vs linux would be the same or clos to te spammer use. But they 
are  fundamentally different and for non-spam the majority of email coming
to your mail server comes from unix machines (like 90% from unix/mac) 
where as for spam proportions are reversed (i.e. 10% from spammer-setup 
unix/mac and 90% from spammer-controlled windows zombies).

That said I disagree with Keith about this being something that we
will "continue to have massive amounts of spam as long as Windows is
the dominant PC operating system". There are ways around the zombie
issue and email architecture can be redesigned so that zombie is not
of much use. We can also setup per-ip policy records that help
distinguish dialup vs static (i.e. MTAMARK or alike).

-- 
William Leibzon
Elan Networks
[email-masked]

Cc: IETF-SMTP <[email-masked]>
Subject: Re: request discussion of two documents on SMTP relaying
To: "Keith Moore" <[email-masked]>
From: "Paul Smith" <[email-masked]>
Date: Sat, 18 Jun 2005 21:18:20 +0100
Sender: [email-masked]

On Sat, 18 Jun 2005 17:55:25 +0100, Keith Moore <[email-masked]> wrote:
> I'd even go so far as to say we're going to continue to have massive  
> amounts of spam as long as Windows is the dominant PC operating system.

I'm sorry, but that's just ridiculous. The only link between Windows and
spam is that lots of people have Windows, and it's relatively easy to use,
so lots of spammers use it. Lots of spammers also use Linux or Macs, you
just see less of that, because there are less of those systems in use by
the 'spammer' sort of person, but if that's all there was, that's what the
spammers would use.

That comment is like saying 'If Ford stopped making cars, there'd be less  
car accidents'.

The operating system is irrelevant. Don't try to turn this into a 'Gates
is a bad guy' argument!.. Whether he is or not is irrelevant to the
spamming issue!

From: Dave Crocker <[email-masked]>
To: IETF-SMTP <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Date: Sat, 18 Jun 2005 10:23:03 -0700
Subject: Re: request discussion of two documents on SMTP relaying
Sender: [email-masked]

>  I think we need a whole set of what I think
>  of as "operational recommendations for email" (ORE would be a good
>  acronym) to improve interoperability between mail clients and mail
>  networks, and also to improve security, make the mail system more

I entirely agree.

The way to achieve that is through incremental specification of best practises 
(or modified technical specifications).

If we require solving the entire set of problems before we publish any portion 
of the improvements, nothing will get published.

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

Date: Sat, 18 Jun 2005 13:11:20 -0400
From: Keith Moore <[email-masked]>
To: Hector Santos <[email-masked]>
Cc: [email-masked]
Subject: Re: request discussion of two documents on SMTP relaying
Sender: [email-masked]

>>| Submission servers MUST NOT disclose the authenticated
>>| identity of the originator of a message (in the Sender,
>>| Received, or any other fields, or in the message body, or
>>| in any SMTP command) unless that identity also appears in
>>| the originator-supplied MAIL FROM field, From header field,
>>| or Reply-To header field.
>>
>>This MUST NOT doesn't fly with option 8.1 in 2476 / 2476bis.
> 
> 
> Althougth you point out a conflict, I personally have concerns with any
> considerations that introduce potential privacy concerns.  This is the
> problem with SUBMITTER proposal.
> 
> From my standpoint 2476 "legalized" the strong authentication requirement
> that removed all user privacy rights.

I believe this needs to be revisited, as the ability to send anonymous 
mail is socially valuable.  Recipients need to be able to block 
anonymous mail if they wish to do so, but the MTS should not block it 
for them.

>>| An SMTP server SHOULD treat an incoming message as a
>>| submission if the SMTP server exists for only the purpose of
>>| mail submission, the server is not listed as an mail
>>| exchanger for any of the domains associated with the MRN, and
>>| the server is not otherwise advertised as a mail relay.
>>
>>I'm not sure what Hector will say about this.  In some cases an
>>MTA just "knows" that it's used as MSA.  Okay, "only" a SHOULD.
> 
> 
> I'm not sure what context is describe in which "hector" will comment
> about this.   Our server is a complete MSA/MTA/MDA system that
> is fundamentially based on:
> 
>     - No Authorization is required for Final Destination Mail
>     - Authorization required for routing.
> 
> The only new concept added to our SMTP server is that the Return Path (MAIL
> FROM) must be verifiable - spoofed or otherwise - it must not be junk and it
> must reflect a valid MX host  - zombie or otherwise.

Not that this is relevant to either of the documents under discussion, 
but it's not consistent with current standards to require that there be 
an MX record for the domain portion of the MAIL FROM address.  It is 
still valid to have only an A record for that address, or for that 
matter, only a AAAA record for that address (though in the latter case 
the address isn't likely to get much mail for awhile).

> 
> Since authorization is a prearrange relationship, return path validation
> overhead is deemed unnecessary.
> 
> 
>>| MONs SHOULD encourage users to configure their MUAs to use
>>| Submission servers (rather than SMTP servers) to submit mail.
>>
>>Yes, that's exactly what you want.  And your definition of MSA
>>doesn't cover "smarthost".  That's a major difference from the
>>2476 terminology if I understand it correctly.  I've no problem
>>with your goal by itself.
> 
> 
> But if ESMTP AUTH or IP relay checking is enforced for ISP users, then port
> 587 is a mute point.

No it's not, first because source IP address checking and many forms of 
SMTP AUTH are broken for reasons mentioned earlier; second because it's 
not reasonable to assume that either all transactions from a particular 
IP address are submissions or all of them are relays.  Submission is (or 
should be) a different operation than relaying in many respects, and 
it's important that there be a clear indication of which operation is 
being requested.

>>Is it not only me who has difficulties with your terminology ?
>>
>>Something's odd, SMTP servers intended to provide submission
>>services (maybe among other services) _are_ submission servers.
> 
> 
> Well, we need to clarify that MSA is not necessary a 2476 based SMTP server
> usually reflected as a "SUBMISSION" server.
> 
> But as I pointed out, to me, RFC 2476 is just an ENFORCEMENT that legalizes
> the requirement to use ESMTP AUTH where otherwise is an optional protocol.
> No more, no less.  

well RFC 2476 does say more than that.

Keith

Date: Sat, 18 Jun 2005 12:55:25 -0400
From: Keith Moore <[email-masked]>
To: Hector Santos <[email-masked]>
Cc: IETF-SMTP <[email-masked]>
Subject: Re: request discussion of two documents on SMTP relaying
Sender: [email-masked]

> I think the documents (SPAMOPS and yours) are necessary in today's era and a
> good start as a new requirements guideline and/or review of the current
> operations for responsible systems.   I think the document(s) should be
> published to help as a new Mail Hosting Summary Requirements Guideline that
> updates, supplements and/or augments RFCs 1123, 2476, 2505, 2821, 2822, etc.

I am of a similar opinion - I think we need a whole set of what I think 
of as "operational recommendations for email" (ORE would be a good 
acronym) to improve interoperability between mail clients and mail 
networks, and also to improve security, make the mail system more 
reliable and its behavior more transparent, make MUA configuration more 
uniform from one network to another, etc.

> However, with that said,  the key problem with both documents is that none
> of the documents clearly address the key issue of how to handle  Anonymous
> Final Destination Mail.
> 
> It may be out of scope,  but it talks about making a clear distinction of
> "WHEN" authorization is required, but it does not address what I believe is
> the #1 problem with the "Email Problem" - when it isn't required.
> 
> The overall issue in Mail Hosting as it is related to TMS (Transaction
> Management and Security) issues boils down to two fundamental key parts of
> SMTP:
> 
> Current Legacy Normal SMTP (BCP) Operations:
> 
>  1 -  Authorization required for remote destination mail (routing)
>  2  - No authorization required for final destination mail (local hosting).
> 
> This is the essence of the Internet Email "Mail Flow" Distribution System -
> it is the commonality of all systems.  I believe the SPAMOPS pretty much is
> describing this basic BCP.

I'm not sure if I'm understanding you here, but I'm guessing you're 
referring to the trend for MONs to require authentication (or some other 
way of knowing who the originator is) but for MRNs to not require 
authentication for messages for local recipients.

If I'm guessing right, a couple of points:
- port 25 blocking, whether you agree with it or not, tends to defeat 
the ability for originators to send directly to recipient's MRNs.
- I believe that the ability to send anonymous mail is valuable and 
there needs to be a way to do it, BUT there also needs to be a way for 
recipients to distinguish anonymous mail from other mail, to impose 
controls and quotas on it, etc.

> 
> As SPAMOPS writes,  #1 includes all the current methods to determine
> authorization, including
> SUBMISSION protocol, IP relay table, ESMTP AUTH, POP B4 SMTP, etc.   I don't
> believe the industry is suffering as much here, however there is a new
> growth of concern on how to handle compromised authorized user or authorized
> MTA machines.   But I don't think we can do much here but use a pattern
> recognization and/or authorized routing limits policy.   This is out of
> scope for SMTP I believe however, I reserve there might be a feedback
> concept to be reviewed.

Compromised machines aren't the only problem - it has become very easy 
for attackers to compromise the signal path between a client and server 
and to introduce spoofing/man-in-the-middle attacks.  This means that 
any authentication method that doesn't provide data integrity and 
server-to-client cryptographic authentication at a minimum, and probably 
data privacy also, is easy to defeat - and attackers are doing just 
this.  So for instance any authentication scheme that relies on 
"trusting" the source IP address is no longer reliable (this includes 
both POP-before-SMTP and networks that "trust" their own addresses)
unless the _entire_ network between client and server is physically 
controlled and _all_ of the routers in that network are filtering 
traffic with that source address from other networks (which essentially 
is never the case).

This is a real problem, and the only general solution is to move to 
better authentication schemes.  And it seems like exactly the thing that 
should be addressed in this kind of document.  This hole is perhaps not 
currently one of the bigger enablers of spam, but it does enable spam, 
and it would be confusing to have different documents provide 
conflicting recommendations about authentication during email submission.

> The "Email Problem"  (Spam or Spoofing) begins pretty much with #2. This is
> where over 60-80% of the problematic mail issues begin.  It the basis for
> the key abuse and exploitation of SMTP.

There are lots of "email problems" :)  Spam is just one of them.

> I like to call #2 as "Anonymous Final Destination" (AFD) transactions
> because for the most part, the major exploit in SMTP is that there is no
> requirement to "verify" the sender for reception of local user and/or local
> hosted domain transactions.  Therefore, the sender is "anonymous" in the
> sense it is not verified nor there is a requirement to do so for final
> destination mail.

I suspect it's probably counterproductive to argue about which 
particular path that spammers use is "the major exploit" - particularly 
because spammers have proven to be very adaptable and have been able to 
change their methods as countermeasures for previous measures were 
deployed.  To have an effective defense against spam and viruses it is 
necessary to block _all_ paths.  At the same time, any solution will 
have to be deployed incrementally.  The recommendations in spamops (and 
my document) are useful steps, even if they don't completely block spam.

The main thing we have to keep in mind is that ill-considered measures 
for blocking spam also end up blocking valid email and/or taking away 
valuable functionality from the email system.  So we need to make sure 
that we make these recommendations with care.

> In other words,  systems adopting the documents can most certainly help
> people run a better server, but it doesn't change or address the fundamental
> problem where there is abuse or non-compliance with the transaction
> parameters.    If it did, then we would not have the "Email Problem" today
> to the tune by current estimates of $13-15 billion industry cost.

I disagree.  We'd still have the same amount of spam that we have now 
even if MRNs were able to authenticate the source of every message they 
received.  I'd even go so far as to say we're going to continue to have 
massive amounts of spam as long as Windows is the dominant PC operating 
system.

> I think the key consideration in SPAMOPS is the encouragement to run a
> dynamic SMTP RCPT validation system as opposed to a post SMTP RCPT
> validation system.   The good news in my perspective is that most good
> systems do perform a Local RCPT validation. I base this on our CBV
> operations.
> 
> But what it doesn't say is how to handle the "verification" of the
> transaction or mail sender when a valid FINAL destination is finally
> determined.   RFC 2476 is ok, but that is not where the problem is located -
> it is located with anonymous  final destination senders.

We don't have a good system for solving this problem yet.  At least the 
last time I looked, SPF and IIM/DomainKeys were both extremely broken.

> Anyway, some might be believe this is out of scope for the documents, but it
> is a critical aspect of the mail distribution problem we are trying to
> address.  So at a very least, this needs to be discussed at some level in
> the documents.

Well, that depends on how you define the scope of the documents.  If you 
try to make the documents describe all of the ways to thwart spam, 
you'll never get them out the door - there are too many paths to sending 
spam and too many for which we don't have good solutions yet.  OTOH if 
you try to make the documents describe best known practices for 
submitting and relaying mail (without limiting it to anti-spam measures 
and without trying to be the comprehensive authority on all anti-spam 
measures) this appears to be a manageable scope.

Keith

Date: Sat, 18 Jun 2005 15:53:48 +0100
From: Tony Finch <[email-masked]>
To: "Robert A. Rosenberg" <[email-masked]>
cc: [email-masked]
Subject: Re: request discussion of two documents on SMTP relaying
Sender: [email-masked]

> > It is unfortunately common for email client software to silently fall back
> > to insecure submission if TLS or AUTH fail in any way
>
> I use Macintosh Eudora (although the Windows version acts the same) where when
> I request an SSL (ie: TLS) session I can designate the SSL as REQUIRED (as
> opposed to Optional [ie: Use if offered in the ESMTP 220 message]).

I can see absolutely no justification for providing an "optional security"
feature (i.e. man-in-the-middle vulnerability). Most MUAs do it and they
are all stupid for doing so.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.

From: "Hector Santos" <[email-masked]>
To: "IETF-SMTP" <[email-masked]>
Cc: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: FYI: Interesting CAM SPAM court case as it relates to 2821 vs 2822
Date: Sat, 18 Jun 2005 04:40:52 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

From: "Robert A. Rosenberg" <[email-masked]>

> Since the act requires an Unsubscribe Link in the Message Body (as
> well as other contact info), how can the judge rule that only header
> info is covered. I think he needs a class in remedial reading (and
> probably logic) based on this ruling.
>
> As an example, if an invalid Unsubscribe URL Link appears in the
> message body wouldn't that qualify as "false information"?

I'm itching to find time to read the case transcript,  but one would think
that might be a valid argument for appeal.

But off hand, I believe the judgment is basically saying the wrong law was
applied here as CAN-SPAM addressed the "fixed" header  information .  It
would be more like a fraud case covered by other laws when dealing with the
body I would think.

What had interest me is that CAN-SPAM does enforce the idea that header
information must be correct from a 2821/2822 stand point. So it would be
nice to get a good definition on the legal minimal requirements.  IOW, is
100% traceability a requirement?  Is anonymity still an option (legally)?

For example, I have been seeing an increase in 2822 headers with a missing
To: Header in phished messages.    2822 only requires  Date: and From:  (822
required Date:, From:, and To: or CC:)  and I believe Lilly has a proposal
to further relax 2822 by removing the From: requirement.     The question
then becomes which is more if a legal requirement (per CAN-SPAM)  2821
headers or 2822 headers?   A missing To is easy to understand - the
2821.RCPT TO is the target address.  But a missing From: is more
questionable since the 2821.MAIL FROM: does not necessary match it.

I guess it doesn't matter under CAN-SPAM as the basic elements of the law
is:

 1 - Don't lie about the sender address
      (Mail From? Sender:? From:? Reply-To:?)

 2 - Don't lie about the Topic (Subject?)

 3 - Give users option to opt out (any proposed standard method??)

and for spammers following these rules, in return they have a "right" to do
business with users.

>From a SMTP standpoint, we can handle #1 (somewhat with recent proposals)
and possibly #2 with a DATA hook or by using Carl Malamud's proposal.  Or
possibly this where a new "SUBJ" SMTP command might be useful.

The body stuff (#3) is less SMTP related, and I guess, this is iffy part of
the law and what you were referring too.

Also, the other interest is that there are pro spammer elements of the
CAN-SPAM act which is basically about Vendor-User contracts.  As long as
they follow the above basic rules, SMTP and Admins needs to be careful about
breaking "vendor-user contracts."   In fact, I believe there was a case
settled last year with IronPort when a big direct mail spammer sued for
breaking vendor-user contracts citing CAN-SPAM.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

Date: Fri, 17 Jun 2005 21:18:34 -0400
To: "IETF-SMTP" <[email-masked]>
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: FYI: Interesting CAM SPAM court case as it relates to 2821 vs 2822
Sender: [email-masked]

At 10:31 -0400 on 06/17/2005, Hector Santos wrote about FYI: 
Interesting CAM SPAM court case as it relates to 2821 :

>CT. RULES FALSE CLAIMS IN EMAIL BODY FALLS OUTSIDE CAN-SPAM
>BNA's Electronic Commerce & Law Report reports that a
>federal court in Idaho has ruled that the CAN-SPAM Act does
>not supply a cause of action for false information included
>in the body of an allegedly unsolicited e-mail message.  The
>court concluded that the anti-spam law only covers false
>information in email headers, not the text of the email.
>Case name is Internet Access Service Providers LLC v. Real
>Networks Inc. Article at
><http://pubs.bna.com/ip/BNA/eip.nsf/is/a0b0y5c4d6>
>For a free trial to the source of this story, visit
>http://www.bna.com/prodcuts/ip/eplr.htm

Since the act requires an Unsubscribe Link in the Message Body (as 
well as other contact info), how can the judge rule that only header 
info is covered. I think he needs a class in remedial reading (and 
probably logic) based on this ruling.

As an example, if an invalid Unsubscribe URL Link appears in the 
message body wouldn't that qualify as "false information"?

From: "Hector Santos" <[email-masked]>
To: <[email-masked]>
Subject: Re: request discussion of two documents on SMTP relaying
Date: Fri, 17 Jun 2005 21:22:00 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

----- Original Message -----
From: "Frank Ellermann" <[email-masked]>
To: <[email-masked]>
Sent: Friday, June 17, 2005 8:36 PM
Subject: Re: request discussion of two documents on SMTP relaying

> > Since authorization is a prearrange relationship, return path
> > validation overhead is deemed unnecessary.
>
> If an authorized user can still use any MAIL FROM he likes
> you're in trouble as soon as one of your users is a zombie.
> Unless you have the encrypted ID and a log-file, see above.
>

A compromised MUA machine is just that - compromised.  I don't see anything
an MSA can do about it short of adding some limits, rates, pattern
recognition controls. At which point, you disable the user account and/or
help the user clean up his machine.

I just had a sysop tell us a story about helping one of his users clean up
his machine after seeing a red flag of increase mail submission activity.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: request discussion of two documents on SMTP relaying
Date:  Sat, 18 Jun 2005 02:36:41 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 51
Sender: [email-masked]

Hector Santos wrote:

 [2476(bis) 8.1 MAY add Sender]
> I personally have concerns with any considerations that
> introduce potential privacy concerns.

It's a point, enabling this option without prior consent of
the unhappy senders would be a very bad idea.  OTOH if the
IESG allows the PRA abuse of v=spf1 policies this 2476bis
option could help to save at least some legit mails.

> 2476 "legalized" the strong authentication requirement
> that removed all user privacy rights.

Same as it always was back to the days of Fido "sysops", as
"sysop" you're interested that users handle all fights they
might get in by themselves without your intervention.  And
for that at least one of their addresses must be "correct".

The worst you can do is to promise "anonymous mail" when you
in fact have plain text log-files ready on your hard disks
and backups for everybody and his dog with a search warrant.

 [snip]
> I'm not sure what context is describe in which "hector" will
> comment about this.   Our server is a complete MSA/MTA/MDA
> system

Yes, that's the point.  Keith apparently envisions a system
where the functions MTA (incl. MX) and MSA are separated, so
you can always say "this box follows 2476 rules" (= MSA) and
"this other box follows 2821 rules" (= MTA).

And the "2821-rules" include stuff like "don't mess with the
mail header" (excl. trace header fields for the moment).

> Since authorization is a prearrange relationship, return path
> validation overhead is deemed unnecessary.

If an authorized user can still use any MAIL FROM he likes
you're in trouble as soon as one of your users is a zombie.
Unless you have the encrypted ID and a log-file, see above.

> if ESMTP AUTH or IP relay checking is enforced for ISP users,
> then port 587 is a mute point.

Still useful to bypass strange "block 25" schemes for roaming
users.  Some ISPs confuse "block 25" with "proper abuse desk".

                           Bye, Frank

Date: Fri, 17 Jun 2005 15:08:59 -0400
From: Michael Hammer <[email-masked]>
Reply-To: Michael Hammer <[email-masked]>
To: Hector Santos <[email-masked]>
Subject: Re: FYI: Interesting CAM SPAM court case as it relates to 2821 vs 2822
Cc: IETF-SMTP <[email-masked]>, IETF-MXCOMP <[email-masked]>
Sender: [email-masked]

Another link which provides a few more details:

http://www.internetcases.com/archives/2005/06/no_spam_with_th_1.html

From: "Hector Santos" <[email-masked]>
To: "IETF-SMTP" <[email-masked]>
Subject: FYI: Interesting CAM SPAM court case as it relates to 2821 vs 2822
Date: Fri, 17 Jun 2005 10:31:56 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

CT. RULES FALSE CLAIMS IN EMAIL BODY FALLS OUTSIDE CAN-SPAM
BNA's Electronic Commerce & Law Report reports that a
federal court in Idaho has ruled that the CAN-SPAM Act does
not supply a cause of action for false information included
in the body of an allegedly unsolicited e-mail message.  The
court concluded that the anti-spam law only covers false
information in email headers, not the text of the email.
Case name is Internet Access Service Providers LLC v. Real
Networks Inc. Article at
<http://pubs.bna.com/ip/BNA/eip.nsf/is/a0b0y5c4d6>
For a free trial to the source of this story, visit
http://www.bna.com/prodcuts/ip/eplr.htm

-- 
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

From: "Hector Santos" <[email-masked]>
To: "IETF-SMTP" <[email-masked]>, "IETF-MXCOMP" <[email-masked]>
Subject: FYI: Interesting CAM SPAM court case as it relates to 2821 vs 2822
Date: Fri, 17 Jun 2005 09:46:56 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

CT. RULES FALSE CLAIMS IN EMAIL BODY FALLS OUTSIDE CAN-SPAM
BNA's Electronic Commerce & Law Report reports that a
federal court in Idaho has ruled that the CAN-SPAM Act does
not supply a cause of action for false information included
in the body of an allegedly unsolicited e-mail message.  The
court concluded that the anti-spam law only covers false
information in email headers, not the text of the email.
Case name is Internet Access Service Providers LLC v. Real
Networks Inc. Article at
<http://pubs.bna.com/ip/BNA/eip.nsf/is/a0b0y5c4d6>
For a free trial to the source of this story, visit
http://www.bna.com/prodcuts/ip/eplr.htm

Date: Thu, 16 Jun 2005 22:59:38 -0400
From: Keith Moore <[email-masked]>
To: Frank Ellermann <[email-masked]>
Cc: [email-masked]
Subject: Re: my Last Call comments on draft-hutzler-spamops-04
Sender: [email-masked]

> One thought I had:  What you call "MON" in your memo should be
> also an "MRN".  Otherwise I'd say that those who don't want to
> get mail (incl. error messages) have no business to send mail.

MONs aren't tied to addresses; MRNs are.  A holder of an 
address needs an MRN to be able to receive mail, but he might
wish (or need) to send mail from that address via an MON 
unrelated to the MRN that accepts incoming mail for that address.

> But they must not send a MAIL FROM "non-local user" (in your
> terminology) where error messages would hit another MON / MRN.
> That BTW is the pretty simple idea of SPF.

and that's one of the reasons SPF is broken.  there are plenty of
valid reasons to send a MAIL FROM that's unrelated to the MON
being used to send it.  

what I would say is that there needs to be a way for originators
to establish the ability to use a particular MAIL FROM address
without having to submit the mail via a particular MON - say
by using a digital signature with a cert signed by the MRN for that
address. 

> When you said 'brain-dead authentication schemes' on the IETF
> list I hope you meant PRA or whatever else, not the simple SPF,

both SPF and anything using PRA fall into that category, for
different reasons.  though some parts of SPF are saner than
others, and I am not sure what you mean by "simple" SPF.

> That started with your "define 'sender'" remark, and checking
> RfC 3834 I found that you also avoided to define it.  But you
> have a very clear concept which of the "return addresses" is
> suited for auto-replies, of course the MAIL FROM, and not some
> braindead (now I say it) PRA / Sender / Reply-To / 2822-From.
> 
> The real "purported responsible address" is the MAIL FROM, the
> PRA idea is just wrong, and tricks with Resent-* addresses are
> madness.

no, the purported responsible address isn't MAIL FROM, nor
should it be.  there are valid reasons to send bounces to an address
other than that of the person responsible for sending the message.
but there is a need to establish that the originator has _permission_
to use that address.

> <rant> If the IESG really allows this PRA-"experiment" abusing
> policies designed for the MAIL FROM they are too incompetent
> to serve the net at large in any position. </rant>  Cowardly
> bypassing a proper "last call" is also a very bad sign.  It
> would not only hurt SPF, but also SMTP.

yup, and I need to start explaining why PRA is a lousy idea.  I've
been too busy with other things.

> > I don't think it's good to require a special-type of MSA for
> > anonymous mail.
> 
> For anonymous mail you need special authentication and privacy
> tricks, the goals are very different from a simple accountable
> sender.  I don't know much about the technical problems, and
> reading the APAS (alt.privacy.anon.serers) FAQ some years ago
> didn't help, but unlike MSAs and SMTP it's not more "simple".
> 
> And draft-hutzler wants to be simple, the audience are normal
> admins at normal ISPs.

well, there's different degrees of anonymity..  you need a different
level of anonymity to protect you if you're whistleblowing
on your employer than you need to protect  you if you're trying
to expose the crimes of the Bush administration.

but I don't want a BCP that precludes anonymous mail, or for
that matter, one that precludes letting a sender use any From
or MAIL FROM address he has permission to use, regardless
of what MON he is using to send the mail.

> > we need to stop pretending that there's a relationship
> > between From address and the MSA used by the originator
> 
> See above, of course there's a relationship between a "sender"
> and the MSA where MAIL FROM "sender" is submitted. 

yes, there's a relationship between the originator and the MON.
yes, the originator needs permission to use the MAIL FROM address,
and perhaps the From header address also.  But there doesn't
need to be a direct relationship between the From address 
or the MAIL FROM address and the MOA.

> It doesn't
> work without this accountability.  With your idea, only an ID
> in the timestamp, you'd get first the "bounces to" the forged
> MAIL FROM, that's reported to abuse@MSA, and then somebody has
> to decode the ID and warn / block the user of the infected box.

really what I think should happen (eventually) is that every MTA
can establish whether the originator had permission to use the
MAIL FROM before it agrees to accept a message.   but that
requires protocol extensions that aren't in scope for the current
document(s).

Keith

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: my Last Call comments on draft-hutzler-spamops-04
Date:  Fri, 17 Jun 2005 02:58:00 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 79
Cc: Keith Moore <[email-masked]>
Sender: [email-masked]

Keith Moore wrote:

> [excerpts from my private reply to Frank's message]

Oops. when I saw your mail in my inbox and here I assumed that
it's the same and kept only the latter for a later reply.

One thought I had:  What you call "MON" in your memo should be
also an "MRN".  Otherwise I'd say that those who don't want to
get mail (incl. error messages) have no business to send mail.

And if that's the case I don't care which particular addresses
in the MON are used as MAIL FROM for mails from this MON.  If
they use [email-masked] it's okay, they're not forced
to read error messages.

But they must not send a MAIL FROM "non-local user" (in your
terminology) where error messages would hit another MON / MRN.
That BTW is the pretty simple idea of SPF.

When you said 'brain-dead authentication schemes' on the IETF
list I hope you meant PRA or whatever else, not the simple SPF,

That started with your "define 'sender'" remark, and checking
RfC 3834 I found that you also avoided to define it.  But you
have a very clear concept which of the "return addresses" is
suited for auto-replies, of course the MAIL FROM, and not some
braindead (now I say it) PRA / Sender / Reply-To / 2822-From.

The real "purported responsible address" is the MAIL FROM, the
PRA idea is just wrong, and tricks with Resent-* addresses are
madness.

<rant> If the IESG really allows this PRA-"experiment" abusing
policies designed for the MAIL FROM they are too incompetent
to serve the net at large in any position. </rant>  Cowardly
bypassing a proper "last call" is also a very bad sign.  It
would not only hurt SPF, but also SMTP.

> I don't think it's good to require a special-type of MSA for
> anonymous mail.

For anonymous mail you need special authentication and privacy
tricks, the goals are very different from a simple accountable
sender.  I don't know much about the technical problems, and
reading the APAS (alt.privacy.anon.serers) FAQ some years ago
didn't help, but unlike MSAs and SMTP it's not more "simple".

And draft-hutzler wants to be simple, the audience are normal
admins at normal ISPs.

> we need to stop pretending that there's a relationship
> between From address and the MSA used by the originator

See above, of course there's a relationship between a "sender"
and the MSA where MAIL FROM "sender" is submitted.  It doesn't
work without this accountability.  With your idea, only an ID
in the timestamp, you'd get first the "bounces to" the forged
MAIL FROM, that's reported to abuse@MSA, and then somebody has
to decode the ID and warn / block the user of the infected box.

Today abuse is the normal case, legit mails are the exception,
So in a draft with "spamops" in its title you can't start to
design a system for anonymous mails, it's completely different
from the daily abuse.

>> It's already an option in RfC 2476 and RfC 2476bis (6.1) for
>> MAIL FROM, and another option for the 822-Sender in (8.1).

> sounds like something that needs to be clarified/fixed in
> 2476bis.

These parts are the same as in 2476, I watched the submit-bis
drafts.  And that (8.1) is "only" an option is one of the many
reasons why PRA is so stupid, who should fix an 2822-sender to
match the MAIL FROM if not the MSA, the MUAs ?  PRA is a FUSSP.

                           Bye, Frank

From: "Hector Santos" <[email-masked]>
To: <[email-masked]>, "Frank Ellermann" <[email-masked]>
Subject: Re: request discussion of two documents on SMTP relaying
Date: Thu, 16 Jun 2005 20:31:47 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

----- Original Message -----
From: "Frank Ellermann" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, June 16, 2005 7:23 PM
Subject: Re: request discussion of two documents on SMTP relaying

> Maybe you could say that an SMTP-after-POP MSA *MUST* enforce
> submission rights (2476bis option 6.1), that should be okay.
> It's still a clumsy scheme (but my old MUA loves it).
>
> One (non-security) issue I heard of was a roaming user trying
> to use POP-after-SMTP while his always-on home box periodically
> checked the POP-server.  So in that case one IP enabled to be
> used for SMTP with a given MAIL FROM was not enough, he needed
> two IPs.
>
> Anyway, it _can_ be better than a plain AUTH LOGIN.  Bye, Frank

In our design, POPB4SMTP is just an extension to the typical "Allow IP
Relay" table.

The POP3's peer IP address is broadcast over RPC protocol to our RPC server
which SMTP server (background thread) has a marshal wire handler to receive
server signals.   Once received by the SMTP server background thread, an
administrator defined "Timeout Window " value is used to cache the IP
address.

When the incoming SMTP session comes in and a route authorization is
required (RCPT TO determines a relay),  the server checks the POPB4SMTP
cache.  If the current session IP address is found in the cache, the route
is allowed.

The SMTP transmission must occur within the timeout period, and by default
the timeout value is set at 1 minute.

Comments:

We encourage ISPs to use ESMTP AUTH for their users and for the most part,
this resolves all the "allow relay" issues.

But I was surprise by some ISP comments to say that a top reason they like
POPB4SMTP is that it reduces thier user support requirements.

To this day, we have no heard of any security related issue with it.
However, believe it or not, it had conflicted with SPF testing operations!
<g>

Here's how:

Now this of course is an implementation issue, but in our system, all
extended sender authorization concepts are SKIPPED if the session is already
authorized using traditional means in place:

    - Allow IP Relay Table
    - POPB4SMTP
    - ESMTP AUTH

This is part of the backward compatibility logic.

So if you are testing SPF by sending something from your POP3 machine and
you happen to have your POP3 client running,   you can bypass the SPF check
because you might be within the 1 minute IP window that had taken place in
the background..

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: request discussion of two documents on SMTP relaying
Date:  Fri, 17 Jun 2005 01:23:23 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 19
Sender: [email-masked]

[email-masked] wrote:

> POP-before-SMTP, OTOH, is very common, and that makes POP
> authentication very relevant indeed. POP-before-SMTP also
> carries with it an additional, unique set of security risks.
> Do we need to document them as well?

Maybe you could say that an SMTP-after-POP MSA *MUST* enforce
submission rights (2476bis option 6.1), that should be okay.
It's still a clumsy scheme (but my old MUA loves it).

One (non-security) issue I heard of was a roaming user trying
to use POP-after-SMTP while his always-on home box periodically
checked the POP-server.  So in that case one IP enabled to be
used for SMTP with a given MAIL FROM was not enough, he needed
two IPs.

Anyway, it _can_ be better than a plain AUTH LOGIN.  Bye, Frank

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: request discussion of two documents on SMTP relaying
Date: Thu, 16 Jun 2005 19:22:39 -0400
Cc: "Robert A. Rosenberg" <[email-masked]>
Sender: [email-masked]

On Thu June 16 2005 17:40, Robert A. Rosenberg wrote:

> I have a question about the above statement. Why does submission of a 
> message warrant more stringent/secure authentication than just 
> reading incoming messages? IOW: If I must do authentication to the 
> POP/IMAP Server before being allowed to read the messages from the 
> server, why is this check not good/strong enough to allow me to 
> submit new messages based on passing the authentication check?

YMMV...

When I access a message via IMAP, the IMAP server that I access is
on a secure network (in fact, it is accessed via the loopback
interface...).  When I send messages, they are (except for messages
to myself) necessarily sent over the Internet, which raises security
issues both for the client and server.

In the general case, downloading/accessing messages involves a
different administrative domain from sending (in particular, sending
involves the recipient's domain's MX hosts, whereas accessing one's
incoming mail involves only one's own mail service provider's host).

Again, YMMV.

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: request discussion of two documents on SMTP relaying
Date: Thu, 16 Jun 2005 19:09:07 -0400
Cc: "Robert A. Rosenberg" <[email-masked]>
Sender: [email-masked]

On Thu June 16 2005 17:17, Robert A. Rosenberg wrote:

> Note: The documents talk about using TLS on the MSA Port587 although 
> it was my impression that aside from Port25, TLS is (per the 
> Well-Known-Port List) associated with the SMTP-over-SSL Port465.

Refer to the ESMTP STARTTLS keyword/command (RFC 3207).

Date: Thu, 16 Jun 2005 17:40:30 -0400
To: [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: request discussion of two documents on SMTP relaying
Sender: [email-masked]

At 11:17 -0400 on 06/16/2005, Keith Moore wrote about Re: request 
discussion of two documents on SMTP relaying:

>It seems likely that there will be some set of people who want to claim
>that POP-before-SMTP is a good way to authenticate originators.  So if
>it's not a good way to do that, we should probably say so.  Similar
>logic would apply in the case of XTND XMIT.   Though I hope that we
>don't find too many more ways that people are currently doing
>authenticated message submission.

I have a question about the above statement. Why does submission of a 
message warrant more stringent/secure authentication than just 
reading incoming messages? IOW: If I must do authentication to the 
POP/IMAP Server before being allowed to read the messages from the 
server, why is this check not good/strong enough to allow me to 
submit new messages based on passing the authentication check?

Date: Thu, 16 Jun 2005 17:31:51 -0400
To: [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: request discussion of two documents on SMTP relaying
Sender: [email-masked]

At 07:33 -0700 on 06/16/2005, Ned Freed wrote about Re: request 
discussion of two documents on SMTP relaying:

>>  > It was my impression (possibly in error) that SMTP AUTH CRAM-MD5 and
>>>  POP's APOP Handshakes encrypt a string that includes a timestamp (and
>>>  thus changes each time) so the encrypted reply is unique and one-time
>>>  (and thus immune to replay attacks) so they are safe from monitoring and
>>>  man-in-the-middle.
>
>>timestamps would not prevent MitM attacks, because the attacker can
>>intercept communications quickly enough that the timestamps are still
>>valid.  I believe timestamps can deter replay attacks if they're
>>implemented correctly.
>
>Both CRAM-MD5 and DIGEST-MD% employ nonces, not timestamps, in their 
>challenges
>and responses. Both are therefore vulnerable to MITM attacks, although
>DIGEST-MD5's use of both client and server nonces prevents an attacker from
>using a precomputed dictionary that corresponds to a known challenge.
>
>And although APOP uses something called a "timestamp", it does not define a
>specific format that would allow a client to check and see if the time is
>within a valid range. Even the suggested format of
>
>    <process-ID.clock@hostname>
>
>is only a suggestion, and even if it were a requirement the lack of a precise
>definition of the "clock" part makes it impossible for a client to check and
>see if the time is within a particular window. So APOP also ends up using
>something that's effectively a nonce, not a timestamp.

The point that I was trying to make with my TimeStamp comment is that 
every connection that I make to the POP Server will supply a unique 
string to encrypt (due to the clock value in the string) so it will 
be immune to replays (although a MitM could hijack the session or add 
its own messages if it were acting as a proxy to the original session 
setup.

>
>>  > As to APOP not being relevant to message submission, it CAN BE if the
>>>  POP session that was initiated via APOP then has XTND XMIT commands
>>>  submitted (to have the POP Server act as a MSA for relating to a MTA).
>
>>Good point.
>
>I'm not sure XTND XMIT is particularly relevant - it has so many
>problems of its own that the added issue of dragging POP authentication
>matters into the MSA realm seems rather trivial.

My point was that since XTND XMIT turns the POP Server into a MSA, so 
long as this is a APOP as opposed to Plain-Text logon Session APOP 
can have a relevancy to Message Submission. I was not addressing any 
problems with its use (or are you saying that using XTND XMIT to 
submit your messages has a different result from using SMTP to a MSA 
Server?).

>
>
>				Ned

Date: Thu, 16 Jun 2005 17:17:21 -0400
To: [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: request discussion of two documents on SMTP relaying
Sender: [email-masked]

--============_-1093163122==_mr============
Content-Type: multipart/alternative; boundary="============_-1093163122==_ma============"

--============_-1093163122==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 14:57 +0100 on 06/16/2005, Tony Finch wrote about Re: request 
discussion of two documents on SMTP relaying:

>On Thu, 16 Jun 2005, Keith Moore wrote:
>>
>>  If I'm not mistaken, TLS does protect against impersonation of a server,
>>  because part of what is used to derive the encryption key is signed with the
>>  server's private key, and the client checks the server certificate using the
>>  CAs' keys that the client already knows about.  Granted this is of little
>>  value if the user gets a popup message that says "we can't validate the
>>  server's key, should we trust it anyway?" and says yes without stopping to
>>  think about whether a MitM attack might be possible.
>
>It is unfortunately common for email client software to silently fall back
>to insecure submission if TLS or AUTH fail in any way

I use Macintosh Eudora (although the Windows version acts the same) 
where when I request an SSL (ie: TLS) session I can designate the SSL 
as REQUIRED (as opposed to Optional [ie: Use if offered in the ESMTP 
220 message]). Thus a failure drops the session. I think other MUAs 
also offer this option. I know that this does not affect the use of 
ESMTP AUTH on Port587 (or Port25) unless the MUA has a Required 
Option for that (which I know the Outlook based MUAs do in their 
Advanced Menus).

Note: The documents talk about using TLS on the MSA Port587 although 
it was my impression that aside from Port25, TLS is (per the 
Well-Known-Port List) associated with the SMTP-over-SSL Port465.

>
>Tony.
>--
>f.a.n.finch  <[email-masked]>  http://dotat.at/
>BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
>GOOD.

--============_-1093163122==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: request discussion of two documents on SMTP
relaying</title></head><body>
<div>At 14:57 +0100 on 06/16/2005, Tony Finch wrote about Re: request
discussion of two documents on SMTP relaying:</div>
<div><br></div>
<blockquote type="cite" cite>On Thu, 16 Jun 2005, Keith Moore
wrote:<br>
&gt;<br>
&gt; If I'm not mistaken, TLS does protect against impersonation of a
server,<br>
&gt; because part of what is used to derive the encryption key is
signed with the<br>
&gt; server's private key, and the client checks the server
certificate using the<br>
&gt; CAs' keys that the client already knows about.&nbsp; Granted this
is of little<br>
&gt; value if the user gets a popup message that says &quot;we can't
validate the<br>
&gt; server's key, should we trust it anyway?&quot; and says yes
without stopping to<br>
&gt; think about whether a MitM attack might be possible.<br>
<br>
It is unfortunately common for email client software to silently fall
back</blockquote>
<blockquote type="cite" cite>to insecure submission if TLS or AUTH
fail in any way<img
src="cid:p06230902bed79a3fda4c@[192.168.1.11].1.0"></blockquote>
<div><br></div>
<div>I use Macintosh Eudora (although the Windows version acts the
same) where when I request an SSL (ie: TLS) session I can designate
the SSL as REQUIRED (as opposed to Optional [ie: Use if offered in the
ESMTP 220 message]). Thus a failure drops the session. I think other
MUAs also offer this option. I know that this does not affect the use
of ESMTP AUTH on Port587 (or Port25) unless the MUA has a Required
Option for that (which I know the Outlook based MUAs do in their
Advanced Menus).</div>
<div><br></div>
<div>Note: The documents talk about using TLS on the MSA Port587
although it was my impression that aside from Port25, TLS is (per the
Well-Known-Port List) associated with the SMTP-over-SSL Port465.</div>
<div><br></div>
<blockquote type="cite" cite><br>
Tony.<br>
--<br>
f.a.n.finch&nbsp; &lt;[email-masked]&gt;&nbsp; http://dotat.at/<br>
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST.
MODERATE OR<br>
GOOD.</blockquote>
<div><br></div>
</body>
</html>
--============_-1093163122==_ma============--
--============_-1093163122==_mr============
Content-Id: <p06230902bed79a3fda4c@[192.168.1.11].1.0>
Content-Type: image/gif; name="!3a-( Sad.gif"
 ; x-mac-type="47494666"
 ; x-mac-creator="474B4F4E"
Content-Disposition: attachment; filename="!3a-( Sad.gif"
Content-Transfer-Encoding: base64

--============_-1093163122==_mr============--

From: Dave Crocker <[email-masked]>
To: John Leslie <[email-masked]>, Keith Moore <[email-masked]>
CC: <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Date: Thu, 16 Jun 2005 13:53:37 -0700
Subject: Re: request discussion of two documents on SMTP relaying
Sender: [email-masked]

>  Nonetheless, I have recently noticed that RFC2476 (Message Submission)
>
>  is being updated.

these are the only two significant changes to the submission doc:

>  o    Support for [SMTP-AUTH] is now mandatory
>
>  o   Message-ID changed from MAY to SHOULD

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

Date: Thu, 16 Jun 2005 16:49:17 -0400
From: Keith Moore <[email-masked]>
To: John Leslie <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: request discussion of two documents on SMTP relaying
Sender: [email-masked]

>    Nonetheless, I have recently noticed that RFC2476 (Message Submission)
> is being updated. Specifically, an I-D has been approved by the IESG and
> forwarded to the rfc-editor:
> 
> http://www.ietf.org/internet-drafts/draft-gellens-submit-bis-02.txt
> 
>    I strongly recommend that folks read this carefully.
> 
>    Hopefully, nothing we might agree on will conflict with this RFC-to-be.
> Alas, some folks have been posting things which strike me as not fully
> consistent with the terminology of RFC 2476bis...

I do intend to try to reconcile my document with 2476bis, at least to
some degree.

>From a quick reading of 2476bis I have some issues with it (and I am
sorry I missed the Last Call), but I want to reread it to see if I like
the wording better on the second pass, and before proposing any
clarifications or fixes.

Keith

Date: Thu, 16 Jun 2005 16:20:47 -0400
From: John Leslie <[email-masked]>
To: Keith Moore <[email-masked]>
Cc: [email-masked]
Subject: Re: request discussion of two documents on SMTP relaying
Sender: [email-masked]

Keith Moore <[email-masked]> wrote:
> 
> Some of you may not be aware (especially if you're not subscribed to the 
> IETF list) that there's a document in Last Call for BCP, 
> draft-hutzler-spamops-04, that makes recommendations for submission of 
> mail and relaying of mail between mail networks.
> 
> I don't believe that this document is written with either adequate 
> precision or accuracy, and frankly I didn't see any easy way to fix it 
> by making small changes to the text.  So n an attempt to produce better 
> language, I wrote my own draft of a document with similar scope, which 
> can be accessed at
> 
> http://www.cs.utk.edu/~moore/opinions/email-submission-recommendations.html

   I'm hesitant to spend much effort discussing until we have some idea
whether the IESG is inclined to approve draft-hutzler-spamops as it stands.

   Nonetheless, I have recently noticed that RFC2476 (Message Submission)
is being updated. Specifically, an I-D has been approved by the IESG and
forwarded to the rfc-editor:

http://www.ietf.org/internet-drafts/draft-gellens-submit-bis-02.txt

   I strongly recommend that folks read this carefully.

   Hopefully, nothing we might agree on will conflict with this RFC-to-be.
Alas, some folks have been posting things which strike me as not fully
consistent with the terminology of RFC 2476bis...

--
John Leslie <[email-masked]>

Date: Thu, 16 Jun 2005 14:50:45 -0400
From: Keith Moore <[email-masked]>
To: Dave Crocker <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: request discussion of two documents on SMTP relaying
Sender: [email-masked]

> The purpose of the spamops specification is to get operators to use certain, 
> strategic procedures.  
> 
> With respect to authentication, it cites some techniques, but is not intended to 
> discuss them in depth.  In other words, the document really does try to avoid 
> the slippery slope of debating nuances about different authentication methods.
> 
> Such a debate seems a sure way to distract the document from it's primary 
> goal, as well as to delay its publication indefinitely.

then again, unless the document supplies some justification for its
recommendations about authentication, people will not accept its 
recommendations - particuarly when doing so is expensive or disruptive. 

I agree with trying to avoid an in-depth discussion.  the question is
how much depth is necessary for the document to serve its purposes.

Keith

From: Dave Crocker <[email-masked]>
To: <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Date: Thu, 16 Jun 2005 09:03:45 -0700
Subject: Re: request discussion of two documents on SMTP relaying
Sender: [email-masked]

>  POP-before-SMTP, OTOH, is very common, and that makes POP authentication
>  very relevant indeed. POP-before-SMTP also carries with it an additional,
>  unique set of security risks. Do we need to document them as well?

The purpose of the spamops specification is to get operators to use certain, 
strategic procedures.  

With respect to authentication, it cites some techniques, but is not intended to 
discuss them in depth.  In other words, the document really does try to avoid 
the slippery slope of debating nuances about different authentication methods.

Such a debate seems a sure way to distract the document from it's primary 
goal, as well as to delay its publication indefinitely.

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

From: Dave Crocker <[email-masked]>
To: Willemien <[email-masked]>, <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Date: Thu, 16 Jun 2005 08:51:59 -0700
Subject: Re: draft-crocker-email-arch-04 add-in
Sender: [email-masked]

>  I was thinking about the draft and I think we need a chapter between
>  section
>
>  3 and 4 about how mail looks at the host level

I do not understand how this improves the architecture discussion.  What 
problems does it solve?

The discussion is already considerably more complex than most folk -- including 
me -- would like.  It needs to be as simple as possible, while still covering 
essential characteristics of the service.

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

Date: Thu, 16 Jun 2005 16:32:41 +0100
From: Tony Finch <[email-masked]>
To: Keith Moore <[email-masked]>
cc: Ned Freed <[email-masked]>, [email-masked], [email-masked]
Subject: Re: request discussion of two documents on SMTP relaying
Sender: [email-masked]

On Thu, 16 Jun 2005, Keith Moore wrote:
>
> Lately I've been thinking that trying to document security concerns
> with authetication methods on a protocol-specific or service-specific
> basis is not the way to go - instead what we might need is a survey of
> authentication methods along with an applicability statement for
> each.

Yes, that was probably the weakest part of the spamops draft, to the
extent that I thought the draft would have been better off without it.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.

Date: Thu, 16 Jun 2005 11:17:23 -0400
From: Keith Moore <[email-masked]>
To: Ned Freed <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: request discussion of two documents on SMTP relaying
Sender: [email-masked]

> > > As to APOP not being relevant to message submission, it CAN BE if the
> > > POP session that was initiated via APOP then has XTND XMIT commands
> > > submitted (to have the POP Server act as a MSA for relating to a MTA).
> 
> > Good point.
> 
> I'm not sure XTND XMIT is particularly relevant - it has so many
> problems of its own that the added issue of dragging POP authentication
> matters into the MSA realm seems rather trivial.
> 
> POP-before-SMTP, OTOH, is very common, and that makes POP authentication very
> relevant indeed. POP-before-SMTP also carries with it an additional, unique set
> of security risks. Do we need to document them as well?

It seems likely that there will be some set of people who want to claim
that POP-before-SMTP is a good way to authenticate originators.  So if
it's not a good way to do that, we should probably say so.  Similar
logic would apply in the case of XTND XMIT.   Though I hope that we
don't find too many more ways that people are currently doing
authenticated message submission.

Lately I've been thinking that trying to document security concerns
with authetication methods on a protocol-specific or service-specific
basis is not the way to go - instead what we might need is a survey of
authentication methods along with an applicability statement for
each.   That way the task of maintaining that list of applicability
statements can get put in the hands of security experts.  But that's
probably a longer-term solution.  I'd hate to make that list part of
the critical path for this document or any other document.

Keith

From: [email-masked]
Cc: Robert A Rosenberg <[email-masked]>, [email-masked]
To: Keith Moore <[email-masked]>
Date: Thu, 16 Jun 2005 07:33:57 -0700 (PDT)
Subject: Re: request discussion of two documents on SMTP relaying
Sender: [email-masked]

> > It was my impression (possibly in error) that SMTP AUTH CRAM-MD5 and
> > POP's APOP Handshakes encrypt a string that includes a timestamp (and
> > thus changes each time) so the encrypted reply is unique and one-time
> > (and thus immune to replay attacks) so they are safe from monitoring and
> > man-in-the-middle.

> timestamps would not prevent MitM attacks, because the attacker can
> intercept communications quickly enough that the timestamps are still
> valid.  I believe timestamps can deter replay attacks if they're
> implemented correctly.

Both CRAM-MD5 and DIGEST-MD% employ nonces, not timestamps, in their challenges
and responses. Both are therefore vulnerable to MITM attacks, although
DIGEST-MD5's use of both client and server nonces prevents an attacker from
using a precomputed dictionary that corresponds to a known challenge.

And although APOP uses something called a "timestamp", it does not define a
specific format that would allow a client to check and see if the time is
within a valid range. Even the suggested format of

    <process-ID.clock@hostname>

is only a suggestion, and even if it were a requirement the lack of a precise
definition of the "clock" part makes it impossible for a client to check and
see if the time is within a particular window. So APOP also ends up using
something that's effectively a nonce, not a timestamp.

> > As to APOP not being relevant to message submission, it CAN BE if the
> > POP session that was initiated via APOP then has XTND XMIT commands
> > submitted (to have the POP Server act as a MSA for relating to a MTA).

> Good point.

I'm not sure XTND XMIT is particularly relevant - it has so many
problems of its own that the added issue of dragging POP authentication
matters into the MSA realm seems rather trivial.

POP-before-SMTP, OTOH, is very common, and that makes POP authentication very
relevant indeed. POP-before-SMTP also carries with it an additional, unique set
of security risks. Do we need to document them as well?

				Ned

Date: Thu, 16 Jun 2005 10:09:54 -0400
From: Keith Moore <[email-masked]>
To: Tony Finch <[email-masked]>
Cc: [email-masked]
Subject: Re: request discussion of two documents on SMTP relaying
Sender: [email-masked]

> It is unfortunately common for email client software to silently fall back
> to insecure submission if TLS or AUTH fail in any way :-(

yup.  though I believe I tried to address this in my document.

Keith

Date: Thu, 16 Jun 2005 14:57:03 +0100
From: Tony Finch <[email-masked]>
To: Keith Moore <[email-masked]>
cc: [email-masked]
Subject: Re: request discussion of two documents on SMTP relaying
Sender: [email-masked]

On Thu, 16 Jun 2005, Keith Moore wrote:
>
> If I'm not mistaken, TLS does protect against impersonation of a server,
> because part of what is used to derive the encryption key is signed with the
> server's private key, and the client checks the server certificate using the
> CAs' keys that the client already knows about.  Granted this is of little
> value if the user gets a popup message that says "we can't validate the
> server's key, should we trust it anyway?" and says yes without stopping to
> think about whether a MitM attack might be possible.

It is unfortunately common for email client software to silently fall back
to insecure submission if TLS or AUTH fail in any way :-(

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.

Date: Thu, 16 Jun 2005 09:24:56 -0400
From: Keith Moore <[email-masked]>
To: [email-masked]
Cc: "Robert A. Rosenberg" <[email-masked]>, [email-masked]
Subject: Re: request discussion of two documents on SMTP relaying
Sender: [email-masked]

> However, even one-time keys cannot prevent the sort of attack involving
> attacker substitution of SMTP session commands.  TLS won't protect
> against impersonation of a server (the attacker can easily choose to
> accept the client certificates and supply session keys, using TLS as if
> it were the server it is impersonating; it can then collect client
> authentication transactions and/or forward certificates and session
> packets to the "real" server, passing responses back to the client and/or
> substituting SMTP commands and data of the attacker's choice).  

If I'm not mistaken, TLS does protect against impersonation of a server, 
because part of what is used to derive the encryption key is signed with 
the server's private key, and the client checks the server certificate 
using the CAs' keys that the client already knows about.  Granted this 
is of little value if the user gets a popup message that says "we can't 
validate the server's key, should we trust it anyway?" and says yes 
without stopping to think about whether a MitM attack might be possible.

> Much of the above is not SMTP-specific.  However SMTP AUTH is asymmetric;
> it provides for the client to authenticate itself to a server but provides
> no mechanism for a client to determine the authenticity of the server.

I believe this statement applies to particular SASL authentication 
methods, not to SASL in general.

Keith

Date: Thu, 16 Jun 2005 09:05:28 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: "Robert A. Rosenberg" <[email-masked]>
Cc: [email-masked]
Subject: Re: request discussion of two documents on SMTP relaying
Sender: [email-masked]

Robert A. Rosenberg wrote:
> 
> 
> 
> At 23:57 -0400 on 06/15/2005, Keith Moore wrote about Re: request
> discussion of two documents on SMTP relaying:
> 
>>  regarding cram-md5: anything that does challenge-response without
>>  changing the key each time is easy to break independent of what hash
>>  algorithm is used, especially in the case of a wireless network where
>>  it's very easy to impersonate a server and mount a man-in-the-middle
>>  attack.  one time passwords (s/key) work okay, but not
>>  challenge-response.  this implicates cram-md5, and also APOP (not that
>>  this is relevant to message submission), and some other things too.
> 
> 
> It was my impression (possibly in error) that SMTP AUTH CRAM-MD5 and
> POP's APOP Handshakes encrypt a string that includes a timestamp (and
> thus changes each time) so the encrypted reply is unique and one-time
> (and thus immune to replay attacks) so they are safe from monitoring and
> man-in-the-middle.

No. See RFC 2195 for a description.  N.B. "impersonating a server".  The
attacker can simply claim to be a particular server and send the "ready
response".  It then collects the client string which can be analyzed at
leisure.  Another type of man-in-the-middle attack is to allow the client
to connect to and authenticate to the "real" server, while collecting the
authentication transaction for later analysis.  A third type of
man-in-the-middle attack is to allow the client to connect to and
authenticate to the "real" server, but to then substitute MAIL FROM,
RCPT TO, and DATA commands of the attackers choice.

Note that the key (the "shared secret" of 2195) is not changed.  In addition
to particular hashing scheme weaknesses, the key can be determined (as the
attacker knows the cleartext (the "ready response" of 2195), the hash
algorithm, and the encrypted text) by many methods, including dictionary
attacks or by guessing values based on the (N.B.) cleartext user name
supplied by the client.

Keith is correct that failure to change the key makes the mechanism
susceptible to attacks involving determination of the key (which can be
used at any time).

However, even one-time keys cannot prevent the sort of attack involving
attacker substitution of SMTP session commands.  TLS won't protect
against impersonation of a server (the attacker can easily choose to
accept the client certificates and supply session keys, using TLS as if
it were the server it is impersonating; it can then collect client
authentication transactions and/or forward certificates and session
packets to the "real" server, passing responses back to the client and/or
substituting SMTP commands and data of the attacker's choice).  Full-blown
VPN might help, but might not have been thoroughly analyzed w.r.t. the
type of attacks discussed above.

Much of the above is not SMTP-specific.  However SMTP AUTH is asymmetric;
it provides for the client to authenticate itself to a server but provides
no mechanism for a client to determine the authenticity of the server. It
is that weakness which allows for impersonating a server as described above.
That fundamental weakness is not addressed by either of the two documents
under discussion.

Date: Thu, 16 Jun 2005 08:58:39 -0400
From: Keith Moore <[email-masked]>
To: "Robert A. Rosenberg" <[email-masked]>
Cc: [email-masked]
Subject: Re: request discussion of two documents on SMTP relaying
Sender: [email-masked]

> It was my impression (possibly in error) that SMTP AUTH CRAM-MD5 and 
> POP's APOP Handshakes encrypt a string that includes a timestamp (and 
> thus changes each time) so the encrypted reply is unique and one-time 
> (and thus immune to replay attacks) so they are safe from monitoring and 
> man-in-the-middle.

timestamps would not prevent MitM attacks, because the attacker can 
intercept communications quickly enough that the timestamps are still 
valid.  I believe timestamps can deter replay attacks if they're 
implemented correctly.

> As to APOP not being relevant to message submission, it CAN BE if the 
> POP session that was initiated via APOP then has XTND XMIT commands 
> submitted (to have the POP Server act as a MSA for relating to a MTA).

good point.

Keith

Date: Thu, 16 Jun 2005 08:55:48 -0400
From: Keith Moore <[email-masked]>
To: "Robert A. Rosenberg" <[email-masked]>
Cc: [email-masked]
Subject: Re: request discussion of two documents on SMTP relaying
Sender: [email-masked]

> I can see a set-up where MSA.Domain resolves via the local DNS when 
> connected to DOMAIN's LAN Network (ie: When the user is getting 
> connectivity from that ISP) while the Internet Facing DNS Servers supply 
> a separate MSA Server Farm address. Which MSA Server Farm you connect to 
> is dependent on what Connectivity you currently have and the selection 
> is automatic without the user needing to alter the MUA Parms.

I can see it too, but it looks pretty ugly.  Some applications break if 
DNS doesn't produce consistent results for any given query from one 
location to another.  Multi-faced DNS does exist, but is not something 
we should encourage as part of a BCP.

(for instance, what's to stop a host from caching the result of a DNS 
query for long enough for that host to move to somewhere else on the 
net, as long as the TTL is respected?  and remember, the host doesn't 
have to move at all in physical space in order to move from one location 
in the network to another - it can be as simple as the host seeing a 
free 802.11 WLAN and deciding to abandon its (more expensive) connection 
to the ISP via GPRS.)

Date: Thu, 16 Jun 2005 08:23:05 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: "Robert A. Rosenberg" <[email-masked]>
Cc: [email-masked]
Subject: Re: request discussion of two documents on SMTP relaying
Sender: [email-masked]

Robert A. Rosenberg wrote:
> 
> At 23:57 -0400 on 06/15/2005, Keith Moore wrote about Re: request
> discussion of two documents on SMTP relaying:
> 
>>  having separate MSAs for roaming users vs. fixed users seems like poor
>>  design.  it's another set of MSAs to maintain, another set of
>>  instructions to provide, another configuration detail users have
>>  to get right, another source of calls to tech support. I don't know
>>  why we should encourage it.
> 
> 
> I can see a set-up where MSA.Domain resolves via the local DNS when
> connected to DOMAIN's LAN Network (ie: When the user is getting
> connectivity from that ISP) while the Internet Facing DNS Servers supply
> a separate MSA Server Farm address. Which MSA Server Farm you connect to
> is dependent on what Connectivity you currently have

and caches, TTLs, and so on.

Date: Thu, 16 Jun 2005 05:23:59 -0400
To: [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: request discussion of two documents on SMTP relaying
Sender: [email-masked]

At 23:57 -0400 on 06/15/2005, Keith Moore wrote about Re: request 
discussion of two documents on SMTP relaying:

>  having separate MSAs for roaming users vs. fixed users seems like poor
>  design.  it's another set of MSAs to maintain, another set of
>  instructions to provide, another configuration detail users have
>  to get right, another source of calls to tech support. I don't know
>  why we should encourage it.

I can see a set-up where MSA.Domain resolves via the local DNS when 
connected to DOMAIN's LAN Network (ie: When the user is getting 
connectivity from that ISP) while the Internet Facing DNS Servers 
supply a separate MSA Server Farm address. Which MSA Server Farm you 
connect to is dependent on what Connectivity you currently have and 
the selection is automatic without the user needing to alter the MUA 
Parms.

Date: Thu, 16 Jun 2005 05:24:58 -0400
To: [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: request discussion of two documents on SMTP relaying
Sender: [email-masked]

At 23:57 -0400 on 06/15/2005, Keith Moore wrote about Re: request 
discussion of two documents on SMTP relaying:

>  regarding cram-md5: anything that does challenge-response without
>  changing the key each time is easy to break independent of what hash
>  algorithm is used, especially in the case of a wireless network where
>  it's very easy to impersonate a server and mount a man-in-the-middle
>  attack.  one time passwords (s/key) work okay, but not
>  challenge-response.  this implicates cram-md5, and also APOP (not that
>  this is relevant to message submission), and some other things too.

It was my impression (possibly in error) that SMTP AUTH CRAM-MD5 and 
POP's APOP Handshakes encrypt a string that includes a timestamp (and 
thus changes each time) so the encrypted reply is unique and one-time 
(and thus immune to replay attacks) so they are safe from monitoring 
and man-in-the-middle.

As to APOP not being relevant to message submission, it CAN BE if the 
POP session that was initiated via APOP then has XTND XMIT commands 
submitted (to have the POP Server act as a MSA for relating to a MTA).

From: "Hector Santos" <[email-masked]>
To: "IETF-SMTP" <[email-masked]>
Subject: SMTP Mail Hosting and TMS Recommendations  [was: Hector's BCP summary outline for SMTP]
Date: Thu, 16 Jun 2005 04:24:16 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

[This is a followup and cleaned up version of my original post.]

              SMTP Mail Hosting and Transaction Management
                    and Security Recommendations
                    version 1.1 - June 16, 2005
               Hector Santos, Santronics Software, Inc.

For what its worth, here is my idea of a good secured SMTP system to
help address the "email problem" with major considerations for backward
compliancy considerations:

This will be presented in sequence as a SMTP STATE flow process.  The
basic assumption is ANONYMOUS sender which means:

    - No ESMTP AUTH is taken place by the client.
    - The IP is not within Local IP relay tables.
    - The client is not white listed.

In other words, the sender is unknown to the SMTP server.   In my view,
an authorized sender does not need any extended TMS consideration other
than to possibly address compromised authorized senders using pattern
recognition methods.

So the following outline is purely based that the sender is not known to
the SMTP using any current BCP authentication/authorization method
currently in place:

1) SMTP Client/Server Compliance.

   SMTP Servers SHOULD perform SMTP client compliancy checking to the
   maximum possible extent. These include:

1.1) CONNECTION

   The SMTP Server MAY perform peer IP address analysis at the
   connection level.

   Aggressive clients with mass connections SHOULD be analyzed for CLASS
   C patterns.

   DNS based lookup methods such as DNSRBL methods SHOULD be delayed
   until the RCPT state is reached.

   SMTP servers SHOULD publish an extended line 220 greeting response
   indicating the system server basic mail policy.

1.2) HELO/EHLO

   The SMTP server SHOULD perform client machine domain syntax checking
   (HELO/EHLO).

   Syntax checking MAY include a Domain Literal Validation (IP vs
   domain IP literal comparison).

   The SMTP server SHOULD perform SHOULD a Local Domain Network IP
   validation check (The IP address does not accurately reflect the
   client domain presented). Since a local domain is under control
   of the SMTP server, the spoofing of the domain is 100% detectable.
   This is a lightweight SPF-like check with no DNS process involved.

   Any advanced HELO/EHLO domain validation concept with considerable
   overhead potential SHOULD be delayed until Remote or Final
   Destination is determined in the RCPT state.

1.3) MAIL FROM

   The SMTP server MUST perform MAIL FROM syntax validation.

   Any advanced MAIL FROM validation concept with considerable overhead
   potential MUST be delayed until Remote or Final Destination is
   determined  in the RCPT state.

1.4) RCPT TO

   The SMTP server MUST perform RCPT TO syntax validation.

   The SMTP server MUST perform LOCAL RCPT VALIDATION to determine
   FINAL/LOCAL vs. ROUTE destination.

   If ROUTE,  a 55x response SHOULD be issued for non-authorized
   transactions.

   IF LOCAL and the session is not authorized, a HELO/EHLO and/or MAIL
   FROM validation SHOULD be performed.

   Due to the nature of SMTP,  HELO/EHLO validation is relaxed and its
   verification is weak.   There are legitimate reasons as to why a
   client machine domain does not match the IP address.

   However, by SMTP 2821 requirements, the return path (MAIL FROM) MUST
   be valid for potential system notification mail flows. A valid return
   path is a fundamental and essential technical requirement for proper
   mail flow,

   Therefore, the SMTP server SHOULD highly consider to perform some
   form of return path validation.  How this is done is a SMTP system
   implementation dependent and considered as a "BLACK BOX"
   concept and is subject to on going R&D.

   If the return path validation fails,  the response SHOULD be 451 or
   551 depending the type, reason or nature for rejection.

1.5) DATA

   If the SMTP server implementation incorporates a Mail Filter Agent
   (mail content analyzers) concept using 3rd party rule based messaging
   technology addressing SPAM or malicious VIRUS mail content,  the SMTP
   server SHOULD perform the dynamic analysis of the mail content during
   the DATA state, after it is received and before the DATA response
   code is issued.

   Any rejection should use a 45x or 55x depending on the 3rd party Mail
   Filter Agent response.

-- 
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

From: "Hector Santos" <[email-masked]>
To: "IETF-SMTP" <[email-masked]>
Subject: Hector's BCP summary outline for SMTP
Date: Thu, 16 Jun 2005 03:37:34 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

For what its worth, here is my idea of a good secured SMTP system with major
consideration for backward considerations:

This will be presented in sequence as a SMTP STATE flow process.  The basic
assumption is ANONYMOUS sender which means:

    - No ESMTP AUTH is taken place by the client.
    - The IP is not within Local IP relay tables.
    - The client is not white listed.

In other words, the sender is unknown to the SMTP server.   In my view, an
authorized sender does not need any extended considerations other than to
possible addressed compromised authorized senders using pattern recognition
methods.  So the following is purely based that the sender is not known to
the SMTP using any current BCP  authentication/authorization method
currently in place:

1) SMTP Servers SHOULD perform SMTP compliancy checking to the maximum
possible extent. These Include:

1.1) CONNECTION

SMTP servers SHOULD publish an extended line 220 greeting response
indicating the system server basic mail policy.

1.2)  HELO/EHLO checking

SMTP Servers SHOULD perform client machine domain syntax checking
(HELO/EHLO).  Syntax checking MAY include a Domain Literal Validation check.

Any advanced HELO/EHLO domain validation concept SHOULD be delayed until
Remote or Final Destination is determined in the RCPT state.

1.3)  MAIL FROM

SMTP Servers MUST perform MAIL FROM syntax validation.

Any advanced MAIL FROM validation concept MUST be delayed until Remote or
Final Destination is determined  in the RCPT state.

1.4)  RCPT TO

SMTP Servers MUST perform RCPT TO syntax validation.

SMTP Servers MUST perform LOCAL RCPT VALIDATION to determine FINAL vs. ROUTE
destination.

If ROUTE,  a 451 response should be issued for non-authorized transactions.

IF LOCAL, a HELO/EHLO and MAIL FROM validation SHOULD be performed.

Due to the nature of SMTP,  HELO/EHLO validation is relaxed.  Its
verification is weak.   However, by
SMTP 2821 requirements.  the MAIL FROM return path MUST be valid for
potential system notification.  A valid return path is a fundamental
requirement for proper mail flow.

Therefore, an SMTP server SHOULD highly consider to perform some form of
RETURN PATH validation.  How this is done is a "BLACK BOX" concept and is
subject to on going R&D.

If the RETURN PATH fails,  the response should be 451 or 551 depending the
type or rejection for rejection.

1.5) DATA

If the SMTP server implementation incorporates a Mail Filter Agent (mail
content analyzers) concept using 3rd party rule based messaging technology
that addresses SPAM or VIRUS mail content,  the SMTP server SHOULD perform
the dynamic analysis of the mail content during the DATA state, after it is
received and before the DATA response code is issued.

A rejection should use a 45x or 55x depending on the 3rd party Mail Filter
Agent response.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

From: "Hector Santos" <[email-masked]>
To: <[email-masked]>
Subject: Re: request discussion of two documents on SMTP relaying
Date: Thu, 16 Jun 2005 01:42:43 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

----- Original Message -----
From: "Frank Ellermann" <[email-masked]>
To: <[email-masked]>
Cc: "Keith Moore" <[email-masked]>
Sent: Wednesday, June 15, 2005 8:53 PM
Subject: Re: request discussion of two documents on SMTP relaying

> | Submission servers MUST NOT disclose the authenticated
> | identity of the originator of a message (in the Sender,
> | Received, or any other fields, or in the message body, or
> | in any SMTP command) unless that identity also appears in
> | the originator-supplied MAIL FROM field, From header field,
> | or Reply-To header field.
>
> This MUST NOT doesn't fly with option 8.1 in 2476 / 2476bis.

Althougth you point out a conflict, I personally have concerns with any
considerations that introduce potential privacy concerns.  This is the
problem with SUBMITTER proposal.

>From my standpoint 2476 "legalized" the strong authentication requirement
that removed all user privacy rights.

> | An SMTP server SHOULD treat an incoming message as a
> | submission if the SMTP server exists for only the purpose of
> | mail submission, the server is not listed as an mail
> | exchanger for any of the domains associated with the MRN, and
> | the server is not otherwise advertised as a mail relay.
>
> I'm not sure what Hector will say about this.  In some cases an
> MTA just "knows" that it's used as MSA.  Okay, "only" a SHOULD.

I'm not sure what context is describe in which "hector" will comment
about this.   Our server is a complete MSA/MTA/MDA system that
is fundamentially based on:

    - No Authorization is required for Final Destination Mail
    - Authorization required for routing.

The only new concept added to our SMTP server is that the Return Path (MAIL
FROM) must be verifiable - spoofed or otherwise - it must not be junk and it
must reflect a valid MX host  - zombie or otherwise.

Since authorization is a prearrange relationship, return path validation
overhead is deemed unnecessary.

> | MONs SHOULD encourage users to configure their MUAs to use
> | Submission servers (rather than SMTP servers) to submit mail.
>
> Yes, that's exactly what you want.  And your definition of MSA
> doesn't cover "smarthost".  That's a major difference from the
> 2476 terminology if I understand it correctly.  I've no problem
> with your goal by itself.

But if ESMTP AUTH or IP relay checking is enforced for ISP users, then port
587 is a mute point.

> Is it not only me who has difficulties with your terminology ?
>
> Something's odd, SMTP servers intended to provide submission
> services (maybe among other services) _are_ submission servers.

Well, we need to clarify that MSA is not necessary a 2476 based SMTP server
usually reflected as a "SUBMISSION" server.

But as I pointed out, to me, RFC 2476 is just an ENFORCEMENT that legalizes
the requirement to use ESMTP AUTH where otherwise is an optional protocol.
No more, no less.   You certainly do not need to use port 587 to perform
ESMTP AUTH.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

From: "Hector Santos" <[email-masked]>
To: "IETF-SMTP" <[email-masked]>
Subject: Re: request discussion of two documents on SMTP relaying
Date: Thu, 16 Jun 2005 01:03:48 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

Keith,

First, I sincerely hope my comments are not taken in any way good or bad or
in any way a reflection on you or anyone else. I am just commenting with my
opinion.  Also, please excuse my tendency of over simplifying problems and
solutions.

I reviewed both documents and I agree with you there needs to be more
clarifications. Overall, when I first read SPAMOPS a week or so ago,  I
pretty much felt it covered the basic issues that are currently in place for
SMTP operations in "responsible systems."   Indeed one of first thing that
did cross my mind was that it could use better rephrasing in certain areas
or better summaries,  itemization in others.  No big deal and given the fact
that it was authored by a team of prominent industry people, I trust all
work was done with careful thought and consideration even if I felt it could
of been done "better" here or there.

I think the documents (SPAMOPS and yours) are necessary in today's era and a
good start as a new requirements guideline and/or review of the current
operations for responsible systems.   I think the document(s) should be
published to help as a new Mail Hosting Summary Requirements Guideline that
updates, supplements and/or augments RFCs 1123, 2476, 2505, 2821, 2822, etc.

However, with that said,  the key problem with both documents is that none
of the documents clearly address the key issue of how to handle  Anonymous
Final Destination Mail.

It may be out of scope,  but it talks about making a clear distinction of
"WHEN" authorization is required, but it does not address what I believe is
the #1 problem with the "Email Problem" - when it isn't required.

The overall issue in Mail Hosting as it is related to TMS (Transaction
Management and Security) issues boils down to two fundamental key parts of
SMTP:

Current Legacy Normal SMTP (BCP) Operations:

 1 -  Authorization required for remote destination mail (routing)
 2  - No authorization required for final destination mail (local hosting).

This is the essence of the Internet Email "Mail Flow" Distribution System -
it is the commonality of all systems.  I believe the SPAMOPS pretty much is
describing this basic BCP.

As SPAMOPS writes,  #1 includes all the current methods to determine
authorization, including
SUBMISSION protocol, IP relay table, ESMTP AUTH, POP B4 SMTP, etc.   I don't
believe the industry is suffering as much here, however there is a new
growth of concern on how to handle compromised authorized user or authorized
MTA machines.   But I don't think we can do much here but use a pattern
recognization and/or authorized routing limits policy.   This is out of
scope for SMTP I believe however, I reserve there might be a feedback
concept to be reviewed.

The "Email Problem"  (Spam or Spoofing) begins pretty much with #2. This is
where over 60-80% of the problematic mail issues begin.  It the basis for
the key abuse and exploitation of SMTP.

I like to call #2 as "Anonymous Final Destination" (AFD) transactions
because for the most part, the major exploit in SMTP is that there is no
requirement to "verify" the sender for reception of local user and/or local
hosted domain transactions.  Therefore, the sender is "anonymous" in the
sense it is not verified nor there is a requirement to do so for final
destination mail.

In other words,  systems adopting the documents can most certainly help
people run a better server, but it doesn't change or address the fundamental
problem where there is abuse or non-compliance with the transaction
parameters.    If it did, then we would not have the "Email Problem" today
to the tune by current estimates of $13-15 billion industry cost.

In short:

    We don't have a problem with GOOD systems. We have a problem with
    BAD systems that we can't get  control or handle on.

SPAMOPS pretty much says:

    Make sure your server knows when final vs. routing is taken place, and
    to enforce an authorization policy for routing.

I think the key consideration in SPAMOPS is the encouragement to run a
dynamic SMTP RCPT validation system as opposed to a post SMTP RCPT
validation system.   The good news in my perspective is that most good
systems do perform a Local RCPT validation. I base this on our CBV
operations.

But what it doesn't say is how to handle the "verification" of the
transaction or mail sender when a valid FINAL destination is finally
determined.   RFC 2476 is ok, but that is not where the problem is located -
it is located with anonymous  final destination senders.

Anyway, some might be believe this is out of scope for the documents, but it
is a critical aspect of the mail distribution problem we are trying to
address.  So at a very least, this needs to be discussed at some level in
the documents.

To me, the future of SMTP and its TMS will largely depend on how we want to
address Anonymous Final Destination mail from several standpoints:

- Verification of process entities with/ minimum SMTP compliance.

- Extended SMTP Response Codes to help admins define better automated flows,
  (white, black, grey listing).

- New R&D on extended SMTP commands, like HEAD to assist new
  "Blast First" PAYLOAD email security protocols.

- New R&D on extended SMTP  client/server handshaking requirements to
  help define optional transaction compliancy policies.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

----- Original Message -----
From: "Keith Moore" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, June 15, 2005 4:55 PM
Subject: request discussion of two documents on SMTP relaying

>
> Folks,
>
> Some of you may not be aware (especially if you're not subscribed to the
> IETF list) that there's a document in Last Call for BCP,
> draft-hutzler-spamops-04, that makes recommendations for submission of
> mail and relaying of mail between mail networks.
>
> I don't believe that this document is written with either adequate
> precision or accuracy, and frankly I didn't see any easy way to fix it
> by making small changes to the text.  So n an attempt to produce better
> language, I wrote my own draft of a document with similar scope, which
> can be accessed at
>
http://www.cs.utk.edu/~moore/opinions/email-submission-recommendations.html
>
> I also believe that this topic needs more discussion among SMTP
> implementors and users before any document can claim to have rough
> consensus.
>
> I would therefore appreciate it if members of this list would read both
> documents and offer comments about either or both of them, particularly
> about areas where the two documents differ.
>
> I'll also send a copy of my Last Call comments to this list, in a
> separate message.
>
> Keith
>
>

Date: Wed, 15 Jun 2005 23:59:32 -0400
From: Keith Moore <[email-masked]>
To: [email-masked]
Subject: Re: my Last Call comments on draft-hutzler-spamops-04
Sender: [email-masked]

[excerpts from my private reply to Frank's message]

>>> anonymous mail is valuable in corner cases
>>
>> Yes.  Somebody will take the technical "sender" responsibility.
>>
>>> the ability to send mail through an MSA not related to the
>>> sender's From address
>>
>> Anon servers as special type of MSA ?  It's an idea,  I don't
>> see where that's a problem in draft-hutzler-spamops.
> 
> I don't think it's good to require a special-type of MSA for anonymous 
> mail.
> 
> I probably should be casting this in terms of "MSA should not disclose 
> originator's authenticated identity for a variety of reasons" rather 
> than "MSA should permit originator to send anonymous mail".  Anonymous 
> mail is only one reason that the MSA should not disclose originator's 
> identity.
> 
>>> operators of MSAs SHOULD NOT restrict authorized submitters
>>> to using particular From addresses, Sender addresses, and/or
>>> MAIL FROM addresses.
>>
>>
>>
>> Quite the contrary.  That's exactly what they SHOULD do, if
>> they are no anon servers. 
> 
> 
> strongly disagree.  that makes the MSA very dysfunctional.
> 
> we need to stop pretending that there's a relationship between From 
> address and the MSA used by the originator - or that the originator's 
> authenticated identity is even usable as a From or Sender address.  that 
> works in corner cases, but not in general, and it forces MUAs to be more 
> complex than they need to be, it prevents users from setting From to 
> other addresses even when (per RFC 822) this is clearly useful.
> 
>> It's already an option in RfC 2476
>> and RfC 2476bis (6.1) for MAIL FROM, and another option for
>> the 822-Sender in (8.1).
> 
> 
> sounds like something that needs to be clarified/fixed in 2476bis.

Keith

Date: Wed, 15 Jun 2005 23:57:41 -0400
From: Keith Moore <[email-masked]>
To: Keith Moore <[email-masked]>
Cc: [email-masked]
Subject: Re: request discussion of two documents on SMTP relaying
Sender: [email-masked]

[sigh.  Frank's message didn't cc the [email-masked] list but was 
sent instead to a newsgroup that was gatewayed to the ietf-smtp list. 
since my MUA isn't configured to send messages to newsgroups it didn't 
send a reply to the list.  and I wrote my reply to Frank as if it were a 
personal reply not a list reply - so I was slightly more candid in that 
reply than I would be on a list.  it was only after I sent my private 
reply to Frank that I realized he had effectively bcc'ed the ietf-smtp 
list.  So for the benefit of the list, this is a slightly edited version 
of my reply to Frank's message.]

Keith Moore wrote:
> 
>> Do you have this somewhere as plain text I-D ? 
> 
> 
> not yet.  I'll republish as an I-D if there seems to be interest.
> 
>>> this topic needs more discussion among SMTP implementors and
>>> users before any document can claim to have rough consensus 
>>
>>
>> Maybe they'll publish draft-hutzler-spamops as "experimental",
>> with the IESG expecting the worst is a fatal lack of fantasy.
>>
>> | A Mail Submission Agent (MSA) is an agent that allows an
>> | authorized originator to submit messages via the Submission
>> | protocol, as defined in RFC 2476 or its successors, on port
>> | 587.
>>
>> Sites MAY also use port 25 for an MSA (gellens-submit-bis-02).
> 
> 
> hmm.  I should definitely try to get in sync with that document.
> 
>> | A Mail Originator Network (MON) is a set of MSAs and MTAs
>> | that accept messages on behalf of authorized users, and relay
>> | each message to the appropriate MDNs for delivery of the
>> | message to its intended recipients.
>> Probably you wanted s/MDN/MRN/ (mail recipient network).
> 
> 
> yes, you're right.  I changed from MDN to MRN in the middle of writing 
> the document to avoid confusion with message disposition notification.
> 
>> | A Mail Reception Network (MRN) is a set of MTAs that accept
>> | mail on behalf of a set of mail domains and deliver each
>> | message to each recipient's message store.
>> Maybe add to MTAs "(some of them also known as 'MX' or Mail
>> eXchanger)".
> 
> 
> the MTAs don't all have to be MXes - only the MTAs that accept mail from 
> other networks need to be MXes.  some mail networks route mail through 
> multiple levels of MTAs internally - maybe for firewall traversal or 
> some other purpose.   all of those MTAs belong to the MRN but not all of 
> them need to be MXes.   really I need to have a figure showing how MRNs 
> and MONs are composed of MTAs, and how they interface to each other, to 
> MUAs, and to message stores, to make this clearer.
> 
>> | A nonlocal recipient address of an MRN is an email address
>> | that is not a local recipient address of that MRN.
>>
>> Okay, that promises to be hardcore, I'm intrigued.
>>
>> | Submission servers MUST NOT disclose the authenticated
>> | identity of the originator of a message (in the Sender,
>> | Received, or any other fields, or in the message body, or
>> | in any SMTP command) unless that identity also appears in
>> | the originator-supplied MAIL FROM field, From header field,
>> | or Reply-To header field.
>> This MUST NOT doesn't fly with option 8.1 in 2476 / 2476bis.
> 
> 
> I don't think they're mutually inconsistent.  It's just that 
> 2476/2476bis doesn't recognize that one of the reasons to not add a 
> Sender field is to avoid disclosing an email address that the originator 
> doesn't want to disclose (maybe because he wants to keep it a secret, or 
> maybe just because he doesn't want to receive mail there).
> 
>> | Submission servers MAY disclose the authenticated identity of
>> | the originator of a message (in the Sender, Received, or
>> | other fields) if that identity already appears in the
>> | MAIL FROM, From, or Reply-To fields in the message as | submitted by 
>> the originator.
>> They MAY disclose it if it's disclosed anyway ?  Well, yes.  Or
>> are you thinking about draft-kucherawy, something like "MSA did
>> check x", where x matches one of the three "return addresses"
>> in your terminology ?
> 
> 
> I'm not familar with that document, I'll have to look at it.
> 
>> | The originator has explicitly consented to the provision of
>> | such information.
>>
>> That might fix the MUST NOT problem mentioned above - the user
>> of an MSA generally accepts its AUP, otherwise he can't use it.
> 
> 
> Yeah, I'm a bit uncomfortable with that, but I don't see any way to 
> prevent ISPs making this a part of their AUPs.  What I hope to do is 
> convince people that it's not reasonable to expect the originator's 
> authenticated identity to be exposed or for it to be a valid email 
> address.  I want to strike a balance between saying that the mail has to 
> be traceable without saying that the originator's identity has to be 
> revealed.
> 
>> | The Submission protocol is a recent addition to the Internet
>> | mail protocol suite.
>>
>> 1998 (RfC 2476) is three years older than 2001 (RfC 2821).
> 
> 
> yes, but SMTP has been around since 1980 or so.
> 
>> | An SMTP server SHOULD treat an incoming message as a
>> | submission if the SMTP server exists for only the purpose of
>> | mail submission, the server is not listed as an mail
>> | exchanger for any of the domains associated with the MRN, and
>> | the server is not otherwise advertised as a mail relay.
>>
>> I'm not sure what Hector will say about this.  In some cases an
>> MTA just "knows" that it's used as MSA.  Okay, "only" a SHOULD.
> 
> 
> I probably need to rewrite this text.  It's fine for an MTA to be 
> configured to be an MSA and to treat all incoming messages as 
> submissions. It's also fine for an MTA to be an MX (or a relay by 
> private arrangement) and treat all incoming messages as relays for a set 
> of "local" domains.  What's tricky is when the same MTA tries to be both 
> MSA and relay - then it needs a reliable way to whether an incoming 
> message is a submission or a relayed message.  Using authenticated 
> identites to know which is which works fine, I think.  Using source IP 
> addresses to determine which is which doesn't work so well.
> 
> 
>> | An SMTP server SHOULD NOT attempt to distinguish submissions
>> | from relayed mail based on the source IP address of the
>> | client.
>>
>> Sorry, I don't get it, what's the idea here, RADIUS is evil ?
>> Or is it about SMTP-after-POP ?  Both ?  Something else ?
> 
> 
> none of those.  the problem is that this behavior makes submission 
> behavior of MUAs location-sensitive, so they fail in odd ways that are 
> hard for users to diagnose.  but it's a SHOULD NOT, so mail networks can 
> make exceptions to the rule if they have a good reason to do so.
> 
>> | A laptop-based MUA which submits mail successfully when
>> | connected to its home network (because the SMTP server
>> | "trusts" the laptop's "home" IP address) might inexplicably
>> | fail to submit mail when connected to another network.
>>
>> The laptop user didn't understand the AUP of his favourite MSA.
>> Or do you want an "MSA for roaming users" != "smarthost" here ?
> 
> 
> having separate MSAs for roaming users vs. fixed users seems like poor 
> design.  it's another set of MSAs to maintain, another set of 
> instructions to provide, another configuration detail users have 
 > to get right, another source of calls to tech support. I don't know
 > why we should encourage it.
> 
>> | MONs SHOULD encourage users to configure their MUAs to use
>> | Submission servers (rather than SMTP servers) to submit mail.
>>
>> Yes, that's exactly what you want.  And your definition of MSA
>> doesn't cover "smarthost".  That's a major difference from the
>> 2476 terminology if I understand it correctly.  I've no problem
>> with your goal by itself.
>>
>> Maybe you could say "dedicated MSA" instead 2476-MSA, if you
>> want "2476-MSA minus smarthost".
> 
> 
> I think there's a gap between our terminologies.  what do you mean by 
> "smarthost" here?
> 
>> In your MON-recommendations I miss strong support for RfC 2476
>> option 6.1.  Again and again I see articles where users think
>> that SMTP AUTH catches "cross-user forgeries".  Only 6.1 does.
> 
> 
> this is a point that needs amplification in my document, and probably 
> needs to be clarified in RFC 2476bis.
> 
> in general, the MSA is not in a position to know that the MAIL FROM 
> address is not authorized for use by the authenticated identity.  the 
> MSA may be in a position to say "yes, this MAIL FROM address _is_ 
> authorized" but can rarely be in a position to reject the message.  The 
> MSA can always say "I won't submit this message with this MAIL FROM 
> address" but that leads to fairly dysfunctional behavior.
> 
>> | This memo takes no position on the blocking of outgoing
>> | traffic on port 25.
>>
>> If this memo is intended to "block" draft-hutzler-spamops, then
>> it might as well say that "blocking port 25" doesn't remove the
>> mail worms from infected systems.  The bot-nets will find some
>> other abuse like DDoS attacks or redirecting spamvertized URLs.
> 
> 
> well, I'm not really trying to "block" the hutzler document, just trying 
> to make sure that any document that does get approved as BCP is 
> well-specified. 
> 
> there are lots of reasons that ISPs block port 25, so I don't see any 
> particular reason to mention bot-nets.  I certainly agree that bot-nets 
> will adapt to port 25 blocking.
> 
>> | MUAs MUST
>>
>> No, MUAs SHOULD.  It's the privilege of users to use old MUAs,
>> and any "upgrade all MUAs" scheme is a doomed FUSSP.  And it's
>> probably a support nightmare.
> 
> 
> well, MUST just means you don't comply with this specification unless you 
> follow the recommendations in the specification.  nobody should expect 
> legacy MUAs, MTAs, MSAs, or anything else to comply with a specification 
> that was written after they were installed.  the whole point of this 
> kind of a specification is to improve existing implementations and 
> practice rather than to legitimize existing implementations and practices 
> that don't work well.
> 
> yes, users will eventually need to upgrade their MUAs.  I think that's a 
> reasonable expectation for anyone who is using MUAs that send cleartext 
> passwords, or for MUAs that can't specify a port # on the submission 
> server, or that can't do STARTTLS and AUTH PLAIN.  but this document 
> doesn't specify a timeframe.
> 
> 
>> | any method requiring transmission of password-equivalent
>> | material, MUST NOT be accepted over an unsecured channel.
>>
>> Is that about CRAM-MD5 ?  Then this memo should be presented
>> again in 2015, and until then draft-hutzler-spamops will do.
> 
> 
> actually this one isn't about about cram-md5, it's more like auth plain 
> and auth login.
> 
> regarding cram-md5: anything that does challenge-response without 
> changing the key each time is easy to break independent of what hash 
> algorithm is used, especially in the case of a wireless network where 
> it's very easy to impersonate a server and mount a man-in-the-middle 
> attack.  one time passwords (s/key) work okay, but not 
> challenge-response.  this implicates cram-md5, and also APOP (not that 
> this is relevant to message submission), and some other things too.
> 
>>
>> | Submission servers and SMTP servers intended to provide
>> | submission services
>>
>> Is it not only me who has difficulties with your terminology ?
>>
>> Something's odd, SMTP servers intended to provide submission
>> services (maybe among other services) _are_ submission servers.
> 
> 
> maybe the terminology needs some tweaking.  maybe I should talk about 
> MSAs, relays, and dual-use MTAs that act as both MSAs and relays 
> depending on the conditions.
> 
> 
> thanks for the careful review and insightful comments.
> 
> Keith

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: my Last Call comments on draft-hutzler-spamops-04
Date:  Thu, 16 Jun 2005 03:55:28 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 55
Cc: Keith Moore <[email-masked]>
Sender: [email-masked]

Keith Moore wrote:

> [Nit]  Eric Allman's name is missing in the authors' list
> at the top of the document.

Indeed, already reported on the ASRG list some weeks ago.

> "originator" might be an even better term than "sender".

| a MAIL command indicating the sender of the mail

...quoth the bible STD 10.  It has a nice picture (figure 1).
It also uses "originator", same semantics as "sender" in this
Internet Standard.

> I am using "sender" more-or-less like it is defined in RFC
> 822.

Oops, that's a standard about the format of text messages.  It
is not limited to SMTP, why do you want it here ?  Also okay:

| trace      =    return                     ; path to sender
|                 1*received                 ; receipt tags
| return     =  "Return-path" ":" route-addr ; return address

So the "sender" is in the "return address" or "Return-Path", in
your memo you have _three_ return addresses, that's different.

> anonymous mail is valuable in corner cases

Yes.  Somebody will take the technical "sender" responsibility.

> the ability to send mail through an MSA not related to the
> sender's From address

Anon servers as special type of MSA ?  It's an idea,  I don't
see where that's a problem in draft-hutzler-spamops.

> operators of MSAs SHOULD NOT restrict authorized submitters
> to using particular From addresses, Sender addresses, and/or
> MAIL FROM addresses.

Quite the contrary.  That's exactly what they SHOULD do, if
they are no anon servers.  It's already an option in RfC 2476
and RfC 2476bis (6.1) for MAIL FROM, and another option for
the 822-Sender in (8.1).

> Figure 1, at the end of section 4 is difficult to read.  I
> can't make heads or tails of it.

It says "roaming users use port 587 (through an entity titled
'INTERNET'), while local users use port 25 or 587 to submit."

'MUA,l' = local user, 'MUA.r' = roaming user.  Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: request discussion of two documents on SMTP relaying
Date:  Thu, 16 Jun 2005 02:53:18 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 140
Cc: Keith Moore <[email-masked]>
Sender: [email-masked]

Keith Moore wrote:

> http://www.cs.utk.edu/~moore/opinions/email-submission-recommendations.html

Do you have this somewhere as plain text I-D ?  I collect some
interesting I-Ds, and your text could fit into my collection:
<http://purl.net/xyzzy/home/test/>

> this topic needs more discussion among SMTP implementors and
> users before any document can claim to have rough consensus

Maybe they'll publish draft-hutzler-spamops as "experimental",
with the IESG expecting the worst is a fatal lack of fantasy.

| A Mail Submission Agent (MSA) is an agent that allows an
| authorized originator to submit messages via the Submission
| protocol, as defined in RFC 2476 or its successors, on port
| 587.

Sites MAY also use port 25 for an MSA (gellens-submit-bis-02).

| A Mail Originator Network (MON) is a set of MSAs and MTAs
| that accept messages on behalf of authorized users, and relay
| each message to the appropriate MDNs for delivery of the
| message to its intended recipients. 

Probably you wanted s/MDN/MRN/ (mail recipient network).

| A Mail Reception Network (MRN) is a set of MTAs that accept
| mail on behalf of a set of mail domains and deliver each
| message to each recipient's message store. 

Maybe add to MTAs "(some of them also known as 'MX' or Mail
eXchanger)".

| A nonlocal recipient address of an MRN is an email address
| that is not a local recipient address of that MRN.

Okay, that promises to be hardcore, I'm intrigued.

| Submission servers MUST NOT disclose the authenticated
| identity of the originator of a message (in the Sender,
| Received, or any other fields, or in the message body, or
| in any SMTP command) unless that identity also appears in
| the originator-supplied MAIL FROM field, From header field,
| or Reply-To header field. 

This MUST NOT doesn't fly with option 8.1 in 2476 / 2476bis.

| Submission servers MAY disclose the authenticated identity of
| the originator of a message (in the Sender, Received, or
| other fields) if that identity already appears in the
| MAIL FROM, From, or Reply-To fields in the message as 
| submitted by the originator. 

They MAY disclose it if it's disclosed anyway ?  Well, yes.  Or
are you thinking about draft-kucherawy, something like "MSA did
check x", where x matches one of the three "return addresses"
in your terminology ?

| The originator has explicitly consented to the provision of
| such information.

That might fix the MUST NOT problem mentioned above - the user
of an MSA generally accepts its AUP, otherwise he can't use it.

| The Submission protocol is a recent addition to the Internet
| mail protocol suite.

1998 (RfC 2476) is three years older than 2001 (RfC 2821).

| An SMTP server SHOULD treat an incoming message as a
| submission if the SMTP server exists for only the purpose of
| mail submission, the server is not listed as an mail
| exchanger for any of the domains associated with the MRN, and
| the server is not otherwise advertised as a mail relay.

I'm not sure what Hector will say about this.  In some cases an
MTA just "knows" that it's used as MSA.  Okay, "only" a SHOULD.

| An SMTP server SHOULD NOT attempt to distinguish submissions
| from relayed mail based on the source IP address of the
| client.

Sorry, I don't get it, what's the idea here, RADIUS is evil ?
Or is it about SMTP-after-POP ?  Both ?  Something else ?

| A laptop-based MUA which submits mail successfully when
| connected to its home network (because the SMTP server
| "trusts" the laptop's "home" IP address) might inexplicably
| fail to submit mail when connected to another network.

The laptop user didn't understand the AUP of his favourite MSA.
Or do you want an "MSA for roaming users" != "smarthost" here ?

| MONs SHOULD encourage users to configure their MUAs to use
| Submission servers (rather than SMTP servers) to submit mail.

Yes, that's exactly what you want.  And your definition of MSA
doesn't cover "smarthost".  That's a major difference from the
2476 terminology if I understand it correctly.  I've no problem
with your goal by itself.

Maybe you could say "dedicated MSA" instead 2476-MSA, if you
want "2476-MSA minus smarthost".

In your MON-recommendations I miss strong support for RfC 2476
option 6.1.  Again and again I see articles where users think
that SMTP AUTH catches "cross-user forgeries".  Only 6.1 does.

| This memo takes no position on the blocking of outgoing
| traffic on port 25.

If this memo is intended to "block" draft-hutzler-spamops, then
it might as well say that "blocking port 25" doesn't remove the
mail worms from infected systems.  The bot-nets will find some
other abuse like DDoS attacks or redirecting spamvertized URLs.

| MUAs MUST

No, MUAs SHOULD.  It's the privilege of users to use old MUAs,
and any "upgrade all MUAs" scheme is a doomed FUSSP.  And it's
probably a support nightmare.

| any method requiring transmission of password-equivalent
| material, MUST NOT be accepted over an unsecured channel.

Is that about CRAM-MD5 ?  Then this memo should be presented
again in 2015, and until then draft-hutzler-spamops will do.

| Submission servers and SMTP servers intended to provide
| submission services

Is it not only me who has difficulties with your terminology ?

Something's odd, SMTP servers intended to provide submission
services (maybe among other services) _are_ submission servers.

                      Bye, Frank

Date: Wed, 15 Jun 2005 16:55:50 -0400
From: Keith Moore <[email-masked]>
Reply-To: [email-masked], [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: my Last Call comments on draft-hutzler-spamops-04
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------010600020600050200060109
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Folks,

It has been suggested to me via private mail that because my Last Call 
comments about this document were sent only to IESG, that people might 
be left with the impression that the disagreement over this document was 
without substance.  For this reason, I've enclosed a copy of my Last 
Call comments about that document as an attachment to this message.

I recommend that followups be sent to the [email-masked] list, as 
this seems to be the most appropriate place for the discussion.

Keith

--------------010600020600050200060109
Content-Type: message/rfc822;
 name="Re: Last Call: 'Email Submission Between Independent Networks' to BCP"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="Re: Last Call: 'Email Submission Between Independent Networks' to BCP"

Date: Thu, 9 Jun 2005 17:45:18 -0400
From: Keith Moore <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Last Call: 'Email Submission Between Independent Networks' to
 BCP

Summary: I believe this document is a good start and has the right intent
and a useful scope, but needs revision (perhaps multiple cycles) before 
publication as BCP.

1. [Nit]  Eric Allman's name is missing in the authors' list at the top of the document.

2. Title may be too broad for the intended scope of the document.

3. [Nit] Section 2, next to last paragraph.  Wording is awkward.  Suggest

   These architectural components are often compressed, by having
   the same software do MSA, MTA and MDA functions.  However the
   requirements for each of these components of the architecture are
   becoming more extensive, causing their separation to be increasingly
   common.

4. Section 3, 2nd paragraph, mistates an important concept.  

change
   Submission typically does entail a relationship between client and server
to
   Submission typically does entail a relationship between the message
   sender and the submission server

5. Section 3, 3rd paragraph

   Specifically, an MSA can choose to reject all postings from MUAs for
   which it has no existing relationship.

change to

   Specifically, an MSA can choose to reject all postings from senders with
   which it has no existing relationship.

Strictly speaking the relationship is with the sender rather than the MUA.  
a single MUA (even a single instance of an MUA) can serve multiple 
senders as long as each sender gives the MUA the appropriate credentials.
(nothing says that the "sender" here has to be a human)

"originator" might be an even better term than "sender".
It might also be worthwhile to define "sender" (or "originator") in section 2.
I am using "sender" more-or-less like it is defined in RFC 822.

6. End of section 3:

The "best practices" bullets seem to worded awkwardly, incorrectly,
and somewhat redundantly.  Here's a stab at better wording:

-----
1st bullet, current text:

   o  Operators of MSAs MUST perform authentication during mail
      submission, based on an existing relationship with the submitting
      entity.  This requirement applies to all mail submission
      mechanisms.

This seems awkward and a bit unclear.  Suggest change to:

   o  MSAs MUST authenticate (verify the identify of) senders prior to 
       relaying mail received from those senders.  This requirement 
       applies to all mail submission mechanisms, whether or not using SMTP.

however this is slightly problematic.  anonymous mail is valuable in
corner cases. even if few recipients will willingly accept it, some will.
so are the ability to send mail through an MSA not related to the
sender's From address, and the ability to send mail on behalf of
multiple senders.  

so a few things should probably be explicitly discussed somewhere:

1. operators of MSAs SHOULD NOT restrict authorized submitters
    to using particular From addresses, Sender addresses, and/or 
    MAIL FROM addresses.

2. an MSA SHOULD NOT expose the sender's authenticated
    identity in the message.

3. the message SHOULD be traceable by the MSA operator to the
    authenticated identity of the user who sent the message, for a 
    reasonable period of time after the message is sent.   such 
    tracing MAY be based on transaction identifiers stored in 
    Received or other fields in the message.

4. nothing in the current suite of internet mail protocols ensures that 
    any address or authentication token associated with a user is
    uniquely bound to that user, stably bound to that user, or 
    has a long-term association with that user.

(I realize there will probably be some disagreement about both
the scope and the specific content of these recommendations, so for
now I'm only suggesting that these topics probably need to be 
touched on to some level of precsion, and the text above is merely
a starting point)

-----
-----
2nd bullet, current text:

   o  For email being received from outside their local operational
       environment, email service operators MUST distinguish between mail
       that will be delivered inside that environment, from mail that is
       to be relayed back out to the Internet.  This allows the MTA to
       restrict this operation, preventing the problem embodied by "open"
       relays.

There are several problems with this:

- it confuses "operational environment" with "domain".  mail delivery
  is delegated to one or more incoming MTAs on a per-domain basis.
  there is not necessarily any correspondence between a "domain"
  and an "operating environment" (which I take to be more-or-less
  a portion of the IP network).
- the "distinguishing" is done by an MTA, not by the operator.
- "delivered inside that environment" seems wrong even if you take
   "environment" to be "domain" because it would have operators 
   (or MTAs) reject mail that is being fowarded from an address 
   in a domain for which that MTA is responsible, to an address in
   a domain for which that MTA is not responsible.
- the "distinguishing" needs to be done on a per-recipient basis,
  rather than a per-message basis, since the same message might be
  addressed to multiple addresses, some inside and some outside of
  the domains for which the MTA is authorized to accept incoming mail. 

as a first approximation, change to:

   o Unless the client has authenticated itself to the MTA on behalf of a
      user authorized by the MTA to send mail to other domains,
      the MTA MUST refuse to accept mail for any address in a domain 
      for which the MTA is not authorized to accept incoming mail.

...but probably this needs more work.  In particular, several 
concepts need to be explained - the concept of domain, and the
concept of an MTA being delegated responsibility for acceptance
of mail to addresses in a domain (which is different than the MTA
being listed as an MX for that domain in DNS).  

as a start, I suggest explaining concepts in section 2 like:
"domain" "domain part of a recipient address" and 
"authorized to accept incoming mail for a domain"
and using those terms in section 3.

-----
3rd bullet, current text:
   o  Mail coming from outside an email operator's local environment,
      and having a RCPT-TO address that resolves to a destination that
      is also outside the local environment, MUST be treated as mail
      submission, rather than mail relaying.  Hence it must be subjected
      to mail submission authorization and validation checks.

"resolves to a destination" is problematic because it forbids mail 
forwarding between domains.  rather it should say "RCPT TO address
that specifies a domain for which the MTA is not responsible"

but more generally, I think this is stated incorrectly.  rather than 
saying "if the recipient is nonlocal, you must treat this as submission"
it should say "you must authenticate the sender before accepting
mail to an address in a domain for which you are not responsible".   
part of the problem is that there are other aspects to submission 
besides authorization and validation checks.  for instance, you don't
want to be adding missing header fields or correcting bogus ones
if you're going to reject the message any way - at best this is
wasteful and at worst it destroys valuable evidence.

   o  MDAs SHALL NOT accept mail to recipients for which that MDA has no
      arrangement to perform delivery.

This seems to be redundant with the above text.

7. Section 4, first paragraph:

what is meant by "enforced privacy"?

   This
   requirement creates a challenge for the provider operating the
   network that hosts the MUA.

it seems a bit odd to speak of a network as "hosting" an MUA when the
MUA is on a mobile platform like a laptop that migrates from one network
to another and may be connected to multiple networks concurrently.

I would say

   This
   requirement creates a challenge for the operator of the
   IP network from which the message was submitted.

8. Figure 1, at the end of section 4 is difficult to read.  I can't make
heads or tails of it.

--------------010600020600050200060109--

Date: Wed, 15 Jun 2005 16:55:30 -0400
From: Keith Moore <[email-masked]>
To: [email-masked]
Subject: request discussion of two documents on SMTP relaying
Sender: [email-masked]

Folks,

Some of you may not be aware (especially if you're not subscribed to the 
IETF list) that there's a document in Last Call for BCP, 
draft-hutzler-spamops-04, that makes recommendations for submission of 
mail and relaying of mail between mail networks.

I don't believe that this document is written with either adequate 
precision or accuracy, and frankly I didn't see any easy way to fix it 
by making small changes to the text.  So n an attempt to produce better 
language, I wrote my own draft of a document with similar scope, which 
can be accessed at
http://www.cs.utk.edu/~moore/opinions/email-submission-recommendations.html

I also believe that this topic needs more discussion among SMTP 
implementors and users before any document can claim to have rough 
consensus.

I would therefore appreciate it if members of this list would read both 
documents and offer comments about either or both of them, particularly 
about areas where the two documents differ.

I'll also send a copy of my Last Call comments to this list, in a 
separate message.

Keith

Date: Wed, 15 Jun 2005 20:30:43 +0100
From: Tony Finch <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: draft-hutzler-spamops-04
Sender: [email-masked]

I very much like the goals of this document, but I think there's a little
room for improvement and clarification, as follows:

Authentication vs. authorization

The draft mostly talks about authentication (authn) rather than
authorization (authz). I'm not sure whether the aim is to require actual
authn of the person sending the message using modern secure protocols, or
if the aim is simply to ensure that a secure authz check is performed.
Because the draft usually talks about authn it seems to be the former, but
then section 5 mentions IP address ACLs which are an authz not authn
technology. What's more, user authentication isn't practical in many
cases, such as email from web servers.

I think this would be clearer if the first bullet point in section 3 were
to say:

   o  Operators of MSAs MUST perform a secure authorization check during
      mail submission, based on an existing relationship with the submitting
      entity.  This requirement applies to all mail submission
      mechanisms.

Section 5 needs some attention too, particularly in the first paragraph.
The second paragraph has been done to death already :-) If it is within
the document's scope to discuss which authn technologies are recommended,
then due attention should be paid in the Security Considerations section;
otherwise I think it would be OK to point the reader elsewhere.

Open relays

The description of the open relay check in the second bullet point in
section 3 appears to ban secondary MXs. It's better to descibe the check
in terms of the message's recipient addresses as they are presented to the
MTA, and not in terms of the message's destination. I suggest:

   o  For email being received from the public Internet without special
      authorization, email service operators MUST distinguish between
      mail domains that they are responsible for and those they are not.
      Messages addressed to domains that the service operator is not
      responsible for MUST be rejected, so that its MTAs do not act as
      "open relays".

Separation of functionality

The third bullet point in section three appears to require MX hosts to act
as MSAs. Although many smaller email systems work in the way it describes,
there are many that don't, and larger systems in particular often have
strictly separated MSA and MX hosts. When I try to come up with
alternative wording to fix the problem, this paragraph becomes redundant
given the contents of the previous two paragraphs. Therefore I suggest it
should be deleted.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.

From: "Willemien" <[email-masked]>
To: <[email-masked]>
Subject: draft-crocker-email-arch-04 add-in
Date: Tue, 14 Jun 2005 17:53:35 +0100
Sender: [email-masked]

Hello lately I do not hear a lot about this draft

I was thinking about the draft and I think we need a chapter between section
3 and 4 about how mail looks at the host level

(very) short first layout

section 4 Hosts level

Email flows over the internet from one host to another.
at this level we just give that hosts names.

Sometimes hosts are missing or merged together but in principle this are
building blocks of the mailsystem.

this level is especially for introduction the mailsystem to beginners in
email and email architecture (like me)

At the host level the mail-architecture looks like:

       Hosts          :   Agents
       level          :   level
                      :
       USER           :
        |             :
        V             :
 /--------------\     :
 |    sending   |     :
 |     mail     |     :    MUA
 |    client    |     :
 \--------------/     :
        |             :
       push           :
        V             :
 /--------------\     :
 |    sending   |     :    MSA
 |     mail     |  ===:============\\
 |    server    |     :   sMTA     ||
 \--------------/     :            ||
        |             :            ||
       push           :            ||
        V             :            ||
 /--------------\     :            ||
 | intermediate |     :            || mail
 |     mail     |     :  (I)MTA    || handling
 |    server    |     :            || system
 \--------------/     :            || MHS
        |             :            ||
        :             :            ||
        :             :            ||
        V             :            ||
 /--------------\     :            ||
 | intermediate |     :            ||
 |     mail     |     :  (I)MTA    ||
 |    server    |     :            ||
 \--------------/     :            ||
        |             :            ||
       push           :            ||
        V             :            ||
 /--------------\     :            ||
 |   receiving  |     :    rMTA    ||
 |     mail     | ====:=====MDA====//
 |    server    |     :     sMS
 \--------------/     :
        |             :
       pull           :
        V             :
 /--------------\     :
 |   receiving  |     :     MRA
 |     mail     |     :     lMS
 |    client    |     :     MUA
 \--------------/     :
        |
        V
      USER

In this diagram I also name the agents that reside in each host.
And gave an indication where the boundaries of the MHS are.

To: [email-masked]
From: wayne <[email-masked]>
Subject:  Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt DNS
Date:  Sun, 05 Jun 2005 14:44:41 -0500
Lines: 32
Cancel-Lock: sha1:GeqdrsEdgP4OjLOe2CtK5mDc6+E=
Sender: [email-masked]

In <VPOP32.1.9.20050602224549.870.1.1.2853140e@[217.155.134.110]> [email-masked] writes:

> OK I know its [RFC1464] old and experimental, but there is no other
> RFC about it so why don't follow it?

RFC1464 describes a way that you *may* store arbitrary information in
TXT RRs, but there is no requirement that you *must* use it.

>> There are no necessary quotes within SPF records, it's
>> just a way to display strings.
>
> That makes it even worse, is it only for display in this draft or are they for real?
> This can have real concequences when you split the record up in
> strings. (Does the second string starts after the 2nd or 3rd ")

The ABNF gives a strict definition of how the SPF records must be.
Most of the places that use quotes are showing records in standard
RFC1034 (bind) syntax form.

>>If you need more space (huge ISP with lots of CIDRs) you can
>>"chain" policies with redirect= (see above more.bar.example).
>
> Would it be not better to be able to chain them within one host?

You are limited to only one SPF record within a single domain name, so
you can't chain SPF records together within one host.

-wayne

To: [email-masked]
From: wayne <[email-masked]>
Subject:  Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt DNS comments
Date:  Sun, 05 Jun 2005 14:33:34 -0500
Lines: 25
Cancel-Lock: sha1:5/e3VNgvN41vyS+MzvbbxZ/aDg8=
Sender: [email-masked]

In <VPOP32.1.7.20050602172121.260.1.1.2853140e@[217.155.134.110]> [email-masked] writes:

> I have posted some questions on the DNS Stuff forum about the SPF draft.

Hi!

Thanks for the review.  Frank has already commented on this, but I'll
add one more note.  I have also posted a reply to the DNS Stuff forum.

> 3.1.1
> An SPF-compliant check SHOULD try to look up and use a record of the SPF type first, before falling back to the TXT type.  However, the client MAY also look up both types in parallel.
> If, for a domain, both types are obtained but their contents do not match, the SPF client SHOULD return a "PermError" result.
>
> The "PermError" rule is NOT mentioned in 4.5 Selecting records.
> Also:
> What to do if both rules are not identical but they both exclude or allow the domain in question?
> Still the SPF client SHOULD return a "PermError" result?

I have moved all of the text about the different lookups out of
section 3.1.1.  I have updated section 4.4 "Record Lookup" to mention
that the lookups can be performed in parallel and I have updated
seciton 4.5 "Selecting Records" to define the PermError results

-wayne

To: Frank Ellermann <[email-masked]>, [email-masked]
From: [email-masked]
Subject: Re: Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt DNS
Date: Thu, 2 Jun 2005 22:45:49 +0100
Sender: [email-masked]

>> http://forums.dnsstuff.com/tool/post/dnsstuff/vpost?id=472797

>The answers you got there appear to be correct - I'm more on
>the ignorant side about some DNS isssues, but SPF forced me
>to get some basic ideas at least theoretically...

>> RFC 1464 is not mentioned in the references
>> the quotes are NOT nessesary (AFAIK)

>...and therefore the first thing I did when I read "1464" was
>to go to Rfc-editor.org and check its status:  experimental,
>1993.

OK I know its old and experimental, but there is no other RFC about it so why don't follow it?

> There are no necessary quotes within SPF records, it's
> just a way to display strings.

That makes it even worse, is it only for display in this draft or are they for real?
This can have real concequences when you split the record up in
strings. (Does the second string starts after the 2nd or 3rd ")

>> The "PermError" rule is NOT mentioned in 4.5 Selecting
>> records.

>Yes, 3.1.1 and 4.5 overlap, and there might be an inconsistency
>for the case "both types exist with different content".  I had
>my own problems with 3.1.1 (essentially I wanted to get rid of
>the offending "PermError").  Something's odd there.

>> What to do if both rules are not identical but they both
>> exclude or allow the domain in question?

>foo.bar.example. IN SPF "v=spf1 +a redirect=more.bar.example"
>foo.bar.example. IN TXT "v=spf1 -a redirect=more.bar.example"

>Something like that ?  Ultimately policies talk about IPs,
>not about domains, the a in these examples is a shorthand for
>a:foo.bar.example, that again is either A or AAAA depending
>on which type of IP you try to match.

>And +a is of course clearly different from -a.  3.1.1 says
>that this is an error if you see it.  4.5 says "use SPF and
>not TXT where possible".

Yes that is also true but I was more thinking about something like:

foo.bar.example. IN SPF "v=spf1 +a -a:more.bar.example ~all"
foo.bar.example. IN TXT "v=spf1 a +a:more.bar.example -all"
same shorthand
(spot the 3 changes)

And you want to test for foo.bar.example
Both allow it but they are NOT identical. What now a PermError or a  Pass?

>> There is a maximum of 64k length for a string in a TXT record

>3.1.4 says that you're free (MAY) to ignore anything that does
>not work with UDP.  Precise limits depend on the TXT or SPF
>records (all of them, not only "v=spf1 " records).

>If you need more space (huge ISP with lots of CIDRs) you can
>"chain" policies with redirect= (see above more.bar.example).

Would it be not better to be able to chain them within one host?

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt DNS comments
Date:  Thu, 02 Jun 2005 23:04:28 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 50
Sender: [email-masked]

[email-masked] wrote:

> http://forums.dnsstuff.com/tool/post/dnsstuff/vpost?id=472797

The answers you got there appear to be correct - I'm more on
the ignorant side about some DNS isssues, but SPF forced me
to get some basic ideas at least theoretically...

> RFC 1464 is not mentioned in the references
> the quotes are NOT nessesary (AFAIK)

...and therefore the first thing I did when I read "1464" was
to go to Rfc-editor.org and check its status:  experimental,
1993.  There are no necessary quotes within SPF records, it's
just a way to display strings.

> The "PermError" rule is NOT mentioned in 4.5 Selecting
> records.

Yes, 3.1.1 and 4.5 overlap, and there might be an inconsistency
for the case "both types exist with different content".  I had
my own problems with 3.1.1 (essentially I wanted to get rid of
the offending "PermError").  Something's odd there.

> What to do if both rules are not identical but they both
> exclude or allow the domain in question?

foo.bar.example. IN SPF "v=spf1 +a redirect=more.bar.example"
foo.bar.example. IN TXT "v=spf1 -a redirect=more.bar.example"

Something like that ?  Ultimately policies talk about IPs,
not about domains, the a in these examples is a shorthand for
a:foo.bar.example, that again is either A or AAAA depending
on which type of IP you try to match.

And +a is of course clearly different from -a.  3.1.1 says
that this is an error if you see it.  4.5 says "use SPF and
not TXT where possible".

> There is a maximum of 64k length for a string in a TXT record

3.1.4 says that you're free (MAY) to ignore anything that does
not work with UDP.  Precise limits depend on the TXT or SPF
records (all of them, not only "v=spf1 " records).

If you need more space (huge ISP with lots of CIDRs) you can
"chain" policies with redirect= (see above more.bar.example).

                      Bye, Frank

To: [email-masked]
Cc: "Hector Santos <[email-masked]> wayne" <[email-masked]>
From: [email-masked]
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt DNS comments
Date: Thu, 2 Jun 2005 17:21:21 +0100
Sender: [email-masked]

Hello, all

I have posted some questions on the DNS Stuff forum about the SPF draft.

To view the thread go to:
http://forums.dnsstuff.com/tool/post/dnsstuff/vpost?id=472797

Other remarks about section 3

3.1
v=spf1 is not conform RFC 1464 (this is about the TXT record not about the SPF record but as long they both MUST be identical)

also
RFC 1464 is not mentioned in the references
the quotes are NOT nessesary (AFAIK)

3.1.1
An SPF-compliant check SHOULD try to look up and use a record of the SPF type first, before falling back to the TXT type.  However, the client MAY also look up both types in parallel.
If, for a domain, both types are obtained but their contents do not match, the SPF client SHOULD return a "PermError" result.

The "PermError" rule is NOT mentioned in 4.5 Selecting records.
Also:
What to do if both rules are not identical but they both exclude or allow the domain in question?
Still the SPF client SHOULD return a "PermError" result?

3.1.3
see
http://forums.dnsstuff.com/tool/post/dnsstuff/vpost?id=472797

also:
There is a maximum of 64k length for a string in a TXT record but do you really think you need longer?
If you do then you have bad luck a TXT record allows only the same lenght.
And then you need multiple TXT records.
for the problems with that see

http://forums.dnsstuff.com/tool/post/dnsstuff/vpost?id=472797

Excuses that I forgot to add a subject line to my last email.

From: "Hector Santos" <[email-masked]>
To: "Robert A. Rosenberg" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Re:
Date: Wed, 1 Jun 2005 12:32:34 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

----- Original Message -----
From: <[email-masked]>
To: "Robert A. Rosenberg" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, June 01, 2005 10:06 AM
Subject: Re: Re:

> >>  Or link them by having the ID field from the Received Header
> >  > replicated in the Received-SPF Header.
> >
> >Been there, discussed that. The "id" component is optional.
> >You can't replicate what isn't there.
>
>
> Is there something simpeler than adding in the SPF draft that for
> SPF compliance an ID field in the received header is a MUST?

The issue depends how SPF is implemented in the host.

The ID will only work 100% if the SPF implementation is direct within SMTP
like at the MAIL FROM or DATA stage.   Here you have control of both the
Received: and the Received-SPF: header.

If the SPF implementation is done as post SMTP process, then it may not any
say control or say over the creation of the current Received: line and an ID
mandate.

PS: I believe the current SPF1 specs recommends a direct SMTP
implementations to minimize bounce attacks.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

To: "Robert A. Rosenberg" <[email-masked]>
Cc: [email-masked]
From: [email-masked]
Subject: Re: Re:
Date: Wed, 1 Jun 2005 15:06:14 +0100
Sender: [email-masked]

At 16:33 -0400 on 05/31/2005, Bruce Lilly wrote about Re: "Header
Reordering", yet again:

>On Tue May 31 2005 15:51, Robert A. Rosenberg wrote:
>
>>  Or link them by having the ID field from the Received Header
>  > replicated in the Received-SPF Header.
>
>Been there, discussed that. The "id" component is optional.
>You can't replicate what isn't there.

Is there something simpeler than adding in the SPF draft that for SPF compliance an ID field in the received header is a MUST?

No I do not take the argument that the draft is unchangable becaurse it discribes the way SPF allready works.
RFC means request for COMMENTS and a draft is even before that stage...

(sorry if you think that i am over reacting on this)

Other small point:

section 5.2 an include that is not an include

In hindsight, the name "include" was poorly chosen.

Then rename it.
Or at least rename it to any of the better names
and use "include" as an obsolete term that also mans the same.
(If you really want to keep it working)

IN RFC's (if that is still where you are aiming at) hindsights should only be about other RFC's not to (pre)-draft- documents