Subject: Re: greylisting done at end of headers, or end of daya (QUIT) ?
From: Hector Santos <[email-masked]>
To: "Carl S. Gutekunst" <[email-masked]>
Cc: [email-masked]
Date: Wed, 31 Jan 2007 20:29:59 -0500
List-Id: <ietf-smtp.imc.org>

Carl S. Gutekunst wrote:
> 
> Let's say I just bought some software; the vendor is about to E-mail me 
> the license key. Or: I just registered at my health insurance company, 
> and they're sending me a confirmation code via E-mail that I must have 
> for access to my medical records. How am I supposed to white list those? 
> Even if I can guess what domain they're sending from, it's still a 
> manual process.

Good point.  What I do is give these special, rare and personal signup 
processes, a special email address that is only temporary and dedicated 
for the specific purpose.  I also use a special "dump box" where 
everything is accepted for these type of stuff where I don't want to 
worry about given them a special address.

This also eliminates the worry about them selling the email address. 
Regardless if they say they won't, I don't believe them. :-)

> The final straw was a small software vendor who had outsourced their 
> license key generation, and the key generator's SMTP client didn't grok 
> 4xx errors and disabled my account. I had to badger them for several 
> days to get the stupid key.
> 
> Bottom line for me is gray listing turned out to be one of the many 
> "clever" techniques that slowed the spam down for a little while, but 
> eventually proved to be more nuisance than help.

I can appreciate your point and opinion, but IMV you are talking about 
highly rare transactions.  By far, the BAD outweight the GOOD and that 
is what most low to mid tier sysops have realized when they isn't really 
must else to go by these days.  Even high tier operations are using 
Greylisting methods. But no doubt, the low to mid tier (the majority of 
the internet) is where you are seeing Greylisting growth.

What I tell my sysops is that if you sit there watching this stuff, 
waiting for the mail, you will increase your doubt wondering whats going 
on or if the good guy is going to try again, and when.   Just let it run 
and it works.  Good Systems are 100% SMTP compliant and will try again. 
    I have YET to see a false positive and if it happen, it was a BADLY 
operated system - which I'm sure happen, but its RARE.

--
HLS

Date: Wed, 31 Jan 2007 16:51:02 -0800
From: "Carl S. Gutekunst" <[email-masked]>
To: Hector Santos <[email-masked]>
CC: [email-masked]
Subject: Re: greylisting done at end of headers, or end of daya (QUIT) ?
Sender: [email-masked]

Hector Santos wrote:
>> I don't see any evidence of that; what I'm seeing now
>> is the zombies will slam the same identical message at you three or four
>> times. 
> huh?  Thats is exactly what GL is suppose to stop.

It stops the first one. It lets the next three right through.

> The whole trick to GL is how good is your whitelist system, including 
> auto-whitelisting ideas, i.e.  When you send email to someone you 
> know, your GL system should auto-whitelist these people because a 
> possible reply from these people might occur.  No need to greylist them.

Let's say I just bought some software; the vendor is about to E-mail me 
the license key. Or: I just registered at my health insurance company, 
and they're sending me a confirmation code via E-mail that I must have 
for access to my medical records. How am I supposed to white list those? 
Even if I can guess what domain they're sending from, it's still a 
manual process.

The final straw was a small software vendor who had outsourced their 
license key generation, and the key generator's SMTP client didn't grok 
4xx errors and disabled my account. I had to badger them for several 
days to get the stupid key.

Bottom line for me is gray listing turned out to be one of the many 
"clever" techniques that slowed the spam down for a little while, but 
eventually proved to be more nuisance than help.

<csg>

Date: Wed, 31 Jan 2007 19:15:24 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: "Carl S. Gutekunst" <[email-masked]>
CC: =?ISO-8859-1?Q?Keld_J=F8rn_Simonsen?= <[email-masked]>, [email-masked]
Subject: Re: greylisting done at end of headers, or end of daya (QUIT) ?
Sender: [email-masked]

Carl S. Gutekunst wrote:

> What surprises me most, though, is that gray-listing is working for
> anyone. The entire assumption behind gray-listing is that zombies don't
> grok 4xx errors. 

Good Guys are 100% SMTP compliant. Bad Guys are not. Thats the theory 
and its true.

> I don't see any evidence of that; what I'm seeing now
> is the zombies will slam the same identical message at you three or four
> times. 

huh?  Thats is exactly what GL is suppose to stop.

> Gray listing used to work pretty well for me a year ago, but I'm
> pretty much ready to turn it off now, all it does is slow down
> legitimate mail.

The whole trick to GL is how good is your whitelist system, including 
auto-whitelisting ideas, i.e.  When you send email to someone you know, 
your GL system should auto-whitelist these people because a possible 
reply from these people might occur.  No need to greylist them.

GL, like any other anti-spam technology is about dealing with the 
"unknown", the "anonymous" sender.  No need for them if your system has 
a clue about the people sending you mail.  Its about building your 
social/business network of friends and business associates.

But your are right, the anonymous "legitimate" transaction will be blocked.

If there anything to learn from all this, is that fact, it is a growing 
feature, whether we like it or not, and what can be done is a BCP that 
provides a enhanced guideline for "retry logic."

For example, prior to implementing GREYLISTING into our SMTP mail 
system,  we had a default 1 hour retry, 72 attempts (3 days) before a 
bounce is created.  When we implemented GREYLISTED, we quickly learned 
that we needed a flexible retry table.  This our default now:

# WCSMTP retry frequencies (in minutes)
[Attempts]
Default=60
Attempt1=5
Attempt2=5
Attempt3=15
Attempt5=30
Attempt10=120
Attempt21=5
Attempt22=5
Attempt23=15
Attempt25=30
Attempt30=120
Attempt40=60
Attempt72=60

So the 1st and 2nd attempt is tried in 5 minutes.  This helped our 
customers who were hitting Greylist servers get their mail delivered.

We probably need some BCP or wording in RFC 2821bis regarding the 
reality of today.

--
HLS

Date: Thu, 1 Feb 2007 00:21:24 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: greylisting done at end of headers, or end of daya (QUIT) ?
Cc: Keld =?iso-8859-1?q?J=F8rn?= Simonsen <[email-masked]>, "Carl S. Gutekunst" <[email-masked]>
Sender: [email-masked]

Carl S. Gutekunst writes:
> Gray listing used to work pretty well for me a year ago, but I'm 
> pretty much ready to turn it off now, all it does is slow down 
> legitimate mail.

I tried that recently and a Douglas Adams quote is called for. The spam 
grew worse when I disabled greylisting. Then I reenabled it and it 
didn't grow any better.

Arnt

Date: Wed, 31 Jan 2007 14:46:10 -0800
From: "Carl S. Gutekunst" <[email-masked]>
To: =?ISO-8859-1?Q?Keld_J=F8rn_Simonsen?= <[email-masked]>
CC: [email-masked]
Subject: Re: greylisting done at end of headers, or end of daya (QUIT) ?
Sender: [email-masked]

[Resending after a botched cut-n-paste]

Keld Jørn Simonsen wrote:
> So what information could be used reliably in an enhanced greylisting?
> What about the subject, and the date?

Date no, for the same reason as Message-ID; template driven systems
insert the current date on the fly.

Subject should work, since in my experience the only variables included
in the Subject will remain the same on retransmission: customer ID,
campaign ID, list name, that sort of thing. Of course, real MTAs don't
frob the subject at all.

What surprises me most, though, is that gray-listing is working for
anyone. The entire assumption behind gray-listing is that zombies don't
grok 4xx errors. I don't see any evidence of that; what I'm seeing now
is the zombies will slam the same identical message at you three or four
times. Gray listing used to work pretty well for me a year ago, but I'm
pretty much ready to turn it off now, all it does is slow down
legitimate mail.

<csg>

Date: Wed, 31 Jan 2007 23:16:12 +0100
From: Keld =?iso-8859-1?Q?J=F8rn?= Simonsen <[email-masked]>
To: "Peter J. Holzer" <[email-masked]>
Cc: [email-masked]
Subject: Re: greylisting done at end of headers, or end of daya (QUIT) ?
Sender: [email-masked]

On Wed, Jan 31, 2007 at 10:21:40PM +0100, Peter J. Holzer wrote:
> On 2007-01-30 13:45:15 -0800, SM wrote:
> > At 12:40 30-01-2007, william(at)elan.net wrote:
> > >Who exactly generates new Message-ID per each transmission???
> > 
> > The MTA sending the message generates a new Message-ID each time it 
> > attempts to send out the message.  I've seen a few cases for 
> > transactional email.
> 
> Yahoo Groups does (or did some time ago) a similar thing with the
> envelope sender: They increment a counter in the sender with each
> delivery attempt. Needless to say that didn't work well with
> greylisting, so I had to whitelist them.

So what information could be used reliably in an enhanced greylisting?
What about the subject, and the date?

best regards
keld

Date: Wed, 31 Jan 2007 22:21:40 +0100
From: "Peter J. Holzer" <[email-masked]>
To: [email-masked]
Subject: Re: greylisting done at end of headers, or end of daya (QUIT) ?
Sender: [email-masked]

--kXdP64Ggrk/fb43R
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2007-01-30 13:45:15 -0800, SM wrote:
> At 12:40 30-01-2007, william(at)elan.net wrote:
> >Who exactly generates new Message-ID per each transmission???
>=20
> The MTA sending the message generates a new Message-ID each time it=20
> attempts to send out the message.  I've seen a few cases for=20
> transactional email.

Yahoo Groups does (or did some time ago) a similar thing with the
envelope sender: They increment a counter in the sender with each
delivery attempt. Needless to say that didn't work well with
greylisting, so I had to whitelist them.

	hp

--=20
   _  | Peter J. Holzer    | I know I'd be respectful of a pirate=20
|_|_) | Sysadmin WSR       | with an emu on his shoulder.
| |   | [email-masked]         |
__/   | http://www.hjp.at/ |	-- Sam in "Freefall"

--kXdP64Ggrk/fb43R
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

--kXdP64Ggrk/fb43R--

Date: Wed, 31 Jan 2007 08:45:08 -0800
To: [email-masked]
From: SM <[email-masked]>
Subject: Re: greylisting done at end of headers, or end of daya (QUIT) ?
Cc: [email-masked]
Sender: [email-masked]

At 16:11 30-01-2007, william(at)elan.net wrote:
>Did you make any correlation as to which server program it actually was?

Unfortunately no.  I recall that it was Java-based.

Regards,
-sm 

Date: Tue, 30 Jan 2007 16:21:39 -0800
From: Claus Assmann <[email-masked]>
To: [email-masked]
Subject: Re: draft-hall-deferrals-00.txt
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Tue, Jan 30, 2007, Tony Finch wrote:

> My main question about this draft is whether the extra complexity compared
> to LMTP is really useful. What is your rationale for it? I have considered

It avoids replies for those recipients that are accepted without
having to check the message. Is it worth it? I don't know...

To make it simpler for people to implement "deferred RCPT reply"
(DRR) it would be better to simply use the LMTP model as most likely
several SMTP clients implement this already and hence existing code
can be reused.

Can we get some consensus which way we want to go:
1. the already known LMTP model.
2. the enhanced model described in draft-hall-deferrals-00.

PS: we might use an extension with a version, e.g.,
220-DRR v1 v2
MAIL From:<...> DRR=v1
where the version numbers correspond to those listed above, and
make one of them (v1?) mandatory to implement. That might allow for
"future enhancements" with "little" effort.

Date: Tue, 30 Jan 2007 16:11:51 -0800 (PST)
From: "william(at)elan.net" <[email-masked]>
To: SM <[email-masked]>
cc: [email-masked]
Subject: Re: greylisting done at end of headers, or end of daya (QUIT) ?
Sender: [email-masked]

On Tue, 30 Jan 2007, SM wrote:

> At 12:40 30-01-2007, william(at)elan.net wrote:
>> Who exactly generates new Message-ID per each transmission???
>
> The MTA sending the message generates a new Message-ID each time it attempts 
> to send out the message.  I've seen a few cases for transactional email.

Did you make any correlation as to which server program it actually was?
Because its not really what I'd expect normal MTA processing message to
ever do (may well be against protocol specs, I guess we can argue about
it here...).

-- 
William Leibzon
Elan Networks
[email-masked]

Date: Tue, 30 Jan 2007 16:07:31 -0800
From: "Carl S. Gutekunst" <[email-masked]>
To: "william(at)elan.net" <[email-masked]>
CC: [email-masked]
Subject: Re: greylisting done at end of headers, or end of daya (QUIT) ?
Sender: [email-masked]

william(at)elan.net wrote:
> Who exactly generates new Message-ID per each transmission??? 

There are legitimate mailing list / bulk mail applications in use by 
Fortune 500 companies that only keep a message template on disk. It's 
the only way to build an application capable of running on a single 
machine and sending personalized versions of a single E-mail to tens of 
millions of people. All the "variable" information, like the recipient's 
name, E-mail address, date, and the Message-ID field, are added on the 
fly while streaming the message to the SMTP receiver. If the message 
gets a 4xx on the first try, the MTA logs the attempt but throws away 
everything else; so indeed the Message-ID changes on each attempt.

No, I don't remember which applications did this, just that I saw it a 
lot at Habeas. And yes, it does play merry hell with duplicate detection 
(and on message tracking -- the Message-ID field is nearly useless).

<csg>

Date: Tue, 30 Jan 2007 23:59:15 +0000
From: Tony Finch <[email-masked]>
To: Frank Ellermann <[email-masked]>
cc: [email-masked]
Subject: Re: draft-hall-inline-dsn-01
Sender: [email-masked]

On Tue, 30 Jan 2007, Frank Ellermann wrote:
> Peter J. Holzer wrote on the ASRG list:
>
> > I was more thinking about nesting SMTP responses like this:
>
> > 250-Message accepted by some recipients. Individual replies follow:
> > 250-250 <[email-masked]> accepted message.
> > 250-550-<[email-masked]> rejected message.
> > 250-550 see http://www.example.com/mail-policy/ for details.
> > 250 250 <[email-masked] accepted message.
>
> Nice.

http://www.courier-mta.org/draft-varshavchik-exdata-smtpext.txt

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
BISCAY FITZROY: NORTHEASTERLY 4 OR 5, BECOMING VARIABLE 3 IN NORTHWEST
FITZROY. MODERATE, LOCALLY ROUGH AT FIRST IN SOUTHWEST FITZROY. SHOWERS IN
SOUTH. GOOD.

Date: Tue, 30 Jan 2007 17:19:53 -0500
From: John C Klensin <[email-masked]>
To: =?UTF-8?Q?Keld_J=C3=B8rn_Simonsen?= <[email-masked]>
cc: [email-masked]
Subject: Re: greylisting done at end of headers, or end of daya (QUIT) ?
Sender: [email-masked]

--On Tuesday, 30 January, 2007 21:25 +0100 Keld JÃ¸rn Simonsen
<[email-masked]> wrote:

>> You don't want to do it on QUIT -- too many systems, in
>> practice, send QUIT and view _any_ response as "ok".  However,
>> there is already provision for returning error replies at the
>> end of the DATA command (i.e., after the CRLF.CRLF).  Such
>> replies are actually necessary with errors like "SIZE limits
>> exceeded" (the reply code isn't called that, of course) and to
>> deal with other problems and MTAs are expected to cope with
>> them.
> 
> OK, the CRLF.CRLF point would be a better place to do it.
> Are there MTAs that fail to requeue the message if they get a
> temporary error at this point?

Probably.  But they shouldn't.  Best you can do, I fear.

This, of course, assumes that the approach is workable at all --
others have commented on that; I haven't thought enough about it
to have an opinion.

    john

Date: Tue, 30 Jan 2007 17:18:39 -0500
From: John C Klensin <[email-masked]>
To: "william(at)elan.net" <[email-masked]>
cc: =?UTF-8?Q?Keld_J=C3=B8rn_Simonsen?= <[email-masked]>, [email-masked]
Subject: Re: greylisting done at end of headers, or end of daya (QUIT) ?
Sender: [email-masked]

--On Tuesday, 30 January, 2007 12:26 -0800 "william(at)elan.net"
<[email-masked]> wrote:

> On Tue, 30 Jan 2007, John C Klensin wrote:
> 
>> You don't want to do it on QUIT -- too many systems, in
>> practice, send QUIT and view _any_ response as "ok".  However,
>> there is already provision for returning error replies at the
>> end of the DATA command (i.e., after the CRLF.CRLF).  Such
>> replies are actually necessary with errors like "SIZE limits
>> exceeded" (the reply code isn't called that, of course) and to
>> deal with other problems and MTAs are expected to cope with
>> them.
> 
> How does server know if client is or is not going to ignore
> reply after DATA?

The server doesn't, any more than the server knows that the
client isn't going to ignore responses to MAIL or RCPT commands.
However the protocol clearly requires that the client pay
attention to those codes.  Paying attention to reply codes after
sending QUIT is much less certain, because it is not clear what
one would do with those codes.  Certainly one cannot negotiate
further with server about them, since the server has not
obligation to read the input stream after acknowledging the QUIT.

    john

Date: Tue, 30 Jan 2007 17:04:30 -0500
From: Tony Hansen <[email-masked]>
To: [email-masked]
Subject: Re: greylisting done at end of headers, or end of daya (QUIT) ?
Sender: [email-masked]

Keld Jørn Simonsen wrote:
> On Tue, Jan 30, 2007 at 02:50:21PM -0500, Tony Hansen wrote:
>> Keld Jørn Simonsen wrote:
>>> I am applying greylisting and it really has some effects on the amount
>>> of spam coming in.
>>> ...
>>> So I ask you: would greylisting based on some unique id like Message-id:
>>> lead to a better result?
>> You're making a few assumptions: 1) There will *be* a message-id you can
>> key off of. 2) The zombies will use different message-id values for each
>> message. I don't think either of these assumptions would necessarily
>> hold true.
> 
> yes, I can imagine this. But maybe you could use some sort of other unique
> identification like a md5sum of the body, or md5sum of the
> header or some such?

I'm sure you'd be better off.

> And why does the FreeBSD people rely on message-id: if this may not
> work, as you indicate?

For the case of missing message-id's, perhaps they wind up not accepting
*any* messages without a message-id, under the assumption that only
illegitimate mail would be missing them, and that's ok because it's
illegitimate mail you're trying to block.

> and would it improve the situation?

It's guaranteed: your mileage *will* vary. :-)

	Tony Hansen
	[email-masked]

Date: Tue, 30 Jan 2007 17:08:08 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: =?ISO-8859-1?Q?Keld_J=F8rn_Simonsen?= <[email-masked]>
CC: [email-masked]
Subject: Re: greylisting done at end of headers, or end of daya (QUIT) ?
Sender: [email-masked]

Keld Jørn Simonsen wrote:

> I am applying greylisting and it really has some effects 
 > on the amount of spam coming in.

Greylisting, I'm afraid to say, is definitely fast becoming a very 
popular feature for our WCSMTP system.

> So I ask you: would greylisting based on some unique id 
 > like Message-id: lead to a better result?

Of course, just to state the obvious. GreyListing is DATA ignorant so 
"message-id" would never be involved. GreyListing is 100% based on the 
TRIPLET entities:

     TRIPLET = HASH(IP, x821.MAILFROM, x821.RCPTO)

See the "officlal" greylist documentation

     http://projects.puremagic.com/greylisting/whitepaper.html

That said, sure, I can see an  enhanced greylisting, like maybe factor 
in a Message-ID with the TRIPLET hash. i.e., catalog the rejected 
message-id: lines, if any, and then use this as a pre-check to the 
greylisting.

Might work, but I am not sure if this would have an effect on the 
already overall high success rate of greylisting.  Typically, if a 
greylist spammer is going to return, it might do so with a different 
message, but it will typically still behave the same with its 1 shot 
attempt deal. I can't imagine a spammer who is greylisted and doesn't 
try again with one TRIPLET value, is going to change his SEND pattern 
with a different TRIPLET value. :-)

In any case, it would be interesting to see what results you find. :-)

> And would there be problems issuing an error code like "file 
 > system full" at the time of the "QUIT" command? I have heard
 > that some genuine MTAs would have problems with recovering
 > from such a message at that time. Which MTAs would that be?

Do you mean as a response to the DATA stage?

I can't imagine any MTA having a problem with a expected support of the 
DATA response, either 250, 4xx, or 5xx.

--
HLS

Date: Wed, 31 Jan 2007 11:05:51 +1300
To: [email-masked]
From: Glenn Anderson <[email-masked]>
Subject: Re: greylisting done at end of headers, or end of daya (QUIT) ?
Sender: [email-masked]

At 8:17 pm +0100 30/1/2007, Keld Jørn Simonsen wrote:
>I am applying greylisting and it really has some effects on the amount
>of spam coming in.
>
>I am running postfix with postgrey, and postgrey only has data available
>from the envelope, such that Message_Id: information is not available. I
>notice that in Freebsd greylisting is done using message-id:
>http://www.freebsd.org/doc/en_US.ISO8859-1/articles/relaydelay/article.html
>
>I see the follwing scenaro for me: a zombie machine sends out spam for
>me, and I greylist it and the zombie does not resend the message to me.
>The the same zombie sends me another spam mail, and then this is
>recognized by postgrey as the first message being resent, as it does not
>know better. I have a feeling that this is going on in some amount of
>cases, but I cannot investigate it as postgrey does not have access to
>the info I would like to log.
>
>So I ask you: would greylisting based on some unique id like Message-id:
>lead to a better result?

In my MTA, I am doing graylisting based on just the IP (not even the 
IP+MAIL FROM+RCPT TO) and I am finding that very little spam gets 
through even that. You might find graylisting on the Message-ID is 
slightly more effective, however it could potentially be less 
effective if a bunch of spambots send out a pile of spam all with the 
same Message-ID because they are all sending exactly the same message.

>And would there be problems issuing an error code like "file system full"
>at the time of the "QUIT" command?

By QUIT time the message has already been received and acknowledged, 
so it is too late to refuse it.

Glenn.

To: "william(at)elan.net" <[email-masked]>
Cc: SM <[email-masked]>, [email-masked]
Subject: Re: greylisting done at end of headers, or end of daya (QUIT) ?
From: [email-masked]
Date: Tue, 30 Jan 2007 17:00:35 -0500
Sender: [email-masked]

--==_Exmh_1170194435_5479P
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

On Tue, 30 Jan 2007 12:40:20 PST, =22william(at)elan.net=22 said:
> Who exactly generates new Message-ID per each transmission???
> Its true that some messages come with no message-id and then my MTA
> would add one in, but ones the field has been added, I'd not expect
> it to be removed if message is retransmitted further.

No sane properly-behaving standards-conformant MTA would do that sort
of nefarious change, because it would totally busticate any software that=

was trying to use the Message-ID: for duplicate detection.

But remember that spammer software is (a) not properly behaving (if it wa=
s,
greylisting wouldn't work - it relies on the fact that most spamware won'=
t
requeue and retry), (b) not standards-conformant, and (c) being run by pe=
ople
who have a vested interest in doing everything they can to prevent you fr=
om
detecting the current message as a duplicate of anything else....

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

--==_Exmh_1170194435_5479P--

Date: Tue, 30 Jan 2007 13:45:15 -0800
To: [email-masked]
From: SM <[email-masked]>
Subject: Re: greylisting done at end of headers, or end of daya (QUIT) ?
Sender: [email-masked]

At 12:40 30-01-2007, william(at)elan.net wrote:
>Who exactly generates new Message-ID per each transmission???

The MTA sending the message generates a new Message-ID each time it 
attempts to send out the message.  I've seen a few cases for 
transactional email.

Regards,
-sm 

Date: Tue, 30 Jan 2007 16:37:08 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Tony Finch <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Degree of adoption for Enhanced Reply Codes?
Sender: [email-masked]

Tony Finch wrote:
> On Mon, 29 Jan 2007, Dave Crocker wrote:
>> I'm interested in getting a basic sense of how useful email operators
>> are finding the Enhanced SMTP reply codes. This isn't for anything
>> formal, but the question came up in discussion and I realized that I had
>> no idea how widespread adoption or use was.
> 
> There was some discussion about this some months ago in the thread
> starting with this post:
> 
> http://www.imc.org/ietf-smtp/mail-archive/msg02756.html
> 
> Probably the most prominent currently maintained MTA that doesn't support
> them is Exim.
> 
> Tony.

No sweat, even long time systems like Wildcat! SMTP doesn't "directly" 
support extended codes and no pressure to do so.

On a support basis, if we see them in a rejection report, we use it as a 
defense to pass the buck

      "Sorry, That isn't our server. WCSMTP doesn't support
       extended codes. You got some other server rejecting
       your mail. Did you turn off IIS?"

--
HLS

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: draft-hall-inline-dsn-01
Date:  Tue, 30 Jan 2007 21:37:41 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 12
Sender: [email-masked]

Peter J. Holzer wrote on the ASRG list:

> I was more thinking about nesting SMTP responses like this:
 
> 250-Message accepted by some recipients. Individual replies follow:
> 250-250 <[email-masked]> accepted message.
> 250-550-<[email-masked]> rejected message.
> 250-550 see http://www.example.com/mail-policy/ for details.
> 250 250 <[email-masked] accepted message.

Nice.

Date: Tue, 30 Jan 2007 12:40:20 -0800 (PST)
From: "william(at)elan.net" <[email-masked]>
To: SM <[email-masked]>
cc: [email-masked]
Subject: Re: greylisting done at end of headers, or end of daya (QUIT) ?
Sender: [email-masked]

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---1747400512-129744138-1170189620=:22667
Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT

On Tue, 30 Jan 2007, SM wrote:

> At 11:17 30-01-2007, Keld Jørn Simonsen wrote:
>> So I ask you: would greylisting based on some unique id like Message-id:
>> lead to a better result?
>
> Some messages do not have a Message-Id.  Some senders generate a new 
> Message-Id on each transmission.  In the second case, the message will never 
> get through as you'll be greylisting it each time.

Who exactly generates new Message-ID per each transmission???
Its true that some messages come with no message-id and then my MTA
would add one in, but ones the field has been added, I'd not expect
it to be removed if message is retransmitted further.

The id entered in Received field is entirely different thing though
and those are in fact unique per each SMTP connection / hop.

-- 
William Leibzon
Elan Networks
[email-masked]
---1747400512-129744138-1170189620=:22667--

Date: Tue, 30 Jan 2007 12:26:02 -0800
To: [email-masked]
From: SM <[email-masked]>
Subject: Re: greylisting done at end of headers, or end of daya (QUIT) ?
Sender: [email-masked]

At 11:17 30-01-2007, Keld Jørn Simonsen wrote:
>So I ask you: would greylisting based on some unique id like Message-id:
>lead to a better result?

Some messages do not have a Message-Id.  Some 
senders generate a new Message-Id on each 
transmission.  In the second case, the message 
will never get through as you'll be greylisting it each time.

Regards,
-sm 

Date: Tue, 30 Jan 2007 12:26:31 -0800 (PST)
From: "william(at)elan.net" <[email-masked]>
To: John C Klensin <[email-masked]>
cc: =?UTF-8?Q?Keld_J=C3=B8rn_Simonsen?= <[email-masked]>, [email-masked]
Subject: Re: greylisting done at end of headers, or end of daya (QUIT) ?
Sender: [email-masked]

On Tue, 30 Jan 2007, John C Klensin wrote:

> You don't want to do it on QUIT -- too many systems, in
> practice, send QUIT and view _any_ response as "ok".  However,
> there is already provision for returning error replies at the
> end of the DATA command (i.e., after the CRLF.CRLF).  Such
> replies are actually necessary with errors like "SIZE limits
> exceeded" (the reply code isn't called that, of course) and to
> deal with other problems and MTAs are expected to cope with them.

How does server know if client is or is not going to ignore reply
after DATA?

-- 
William Leibzon
Elan Networks
[email-masked]

Date: Tue, 30 Jan 2007 21:25:56 +0100
From: Keld =?iso-8859-1?Q?J=F8rn?= Simonsen <[email-masked]>
To: John C Klensin <[email-masked]>
Cc: [email-masked]
Subject: Re: greylisting done at end of headers, or end of daya (QUIT) ?
Sender: [email-masked]

On Tue, Jan 30, 2007 at 02:48:42PM -0500, John C Klensin wrote:
> 
> 
> --On Tuesday, 30 January, 2007 20:17 +0100 Keld Jørn Simonsen
> <[email-masked]> wrote:
> 
> > And would there be problems issuing an error code like "file
> > system full" at the time of the "QUIT" command? I have heard
> > that some genuine MTAs would have problems with recovering
> > from such a message at that time. Which MTAs would that be?
> 
> You don't want to do it on QUIT -- too many systems, in
> practice, send QUIT and view _any_ response as "ok".  However,
> there is already provision for returning error replies at the
> end of the DATA command (i.e., after the CRLF.CRLF).  Such
> replies are actually necessary with errors like "SIZE limits
> exceeded" (the reply code isn't called that, of course) and to
> deal with other problems and MTAs are expected to cope with them.

OK, the CRLF.CRLF point would be a better place to do it.
Are there MTAs that fail to requeue the message if they get a temporary
error at this point?

best regards
keld

Date: Tue, 30 Jan 2007 21:18:11 +0100
From: Keld =?iso-8859-1?Q?J=F8rn?= Simonsen <[email-masked]>
To: Tony Hansen <[email-masked]>
Cc: [email-masked]
Subject: Re: greylisting done at end of headers, or end of daya (QUIT) ?
Sender: [email-masked]

On Tue, Jan 30, 2007 at 02:50:21PM -0500, Tony Hansen wrote:
> 
> Keld Jørn Simonsen wrote:
> > I am applying greylisting and it really has some effects on the amount
> > of spam coming in.
> > ...
> > So I ask you: would greylisting based on some unique id like Message-id:
> > lead to a better result?
> 
> You're making a few assumptions: 1) There will *be* a message-id you can
> key off of. 2) The zombies will use different message-id values for each
> message. I don't think either of these assumptions would necessarily
> hold true.

yes, I can imagine this. But maybe you could use some sort of other unique
identification like a md5sum of the body, or md5sum of the
header or some such?

And why does the FreeBSD people rely on message-id: if this may not
work, as you indicate?

and would it improve the situation?

best regards
keld

Date: Tue, 30 Jan 2007 14:50:21 -0500
From: Tony Hansen <[email-masked]>
To: [email-masked]
Subject: Re: greylisting done at end of headers, or end of daya (QUIT) ?
Sender: [email-masked]

Keld Jørn Simonsen wrote:
> I am applying greylisting and it really has some effects on the amount
> of spam coming in.
> ...
> So I ask you: would greylisting based on some unique id like Message-id:
> lead to a better result?

You're making a few assumptions: 1) There will *be* a message-id you can
key off of. 2) The zombies will use different message-id values for each
message. I don't think either of these assumptions would necessarily
hold true.

	Tony Hansen
	[email-masked]

Date: Tue, 30 Jan 2007 14:48:42 -0500
From: John C Klensin <[email-masked]>
To: =?UTF-8?Q?Keld_J=C3=B8rn_Simonsen?= <[email-masked]>, [email-masked]
Subject: Re: greylisting done at end of headers, or end of daya (QUIT) ?
Sender: [email-masked]

--On Tuesday, 30 January, 2007 20:17 +0100 Keld JÃ¸rn Simonsen
<[email-masked]> wrote:

> And would there be problems issuing an error code like "file
> system full" at the time of the "QUIT" command? I have heard
> that some genuine MTAs would have problems with recovering
> from such a message at that time. Which MTAs would that be?

You don't want to do it on QUIT -- too many systems, in
practice, send QUIT and view _any_ response as "ok".  However,
there is already provision for returning error replies at the
end of the DATA command (i.e., after the CRLF.CRLF).  Such
replies are actually necessary with errors like "SIZE limits
exceeded" (the reply code isn't called that, of course) and to
deal with other problems and MTAs are expected to cope with them.

     john

Date: Tue, 30 Jan 2007 19:45:40 +0000
From: Tony Finch <[email-masked]>
To: "Eric A. Hall" <[email-masked]>
cc: [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-hall-deferrals-00.txt
Sender: [email-masked]

My main question about this draft is whether the extra complexity compared
to LMTP is really useful. What is your rationale for it? I have considered
writing a draft that simply defines how to turn on RFC 2033 data responses
in SMTP, without specifying any significant new protocol features.

Having said that, here are some comments on the technical parts of your
draft. (I'll ignore stylistic matters for now.)

The document title should be the same as the name of the service
extension. The name "deferrals" is very bad: it doesn't say what is
deferred or for how long. I'd suggest a long-ish name like "per-recipient
data replies" with a keyword like "DATA-PER-RCPT".

Another way of dealing with the problem currently is to give a 450 reply
to RCPT commands that have different policies from the first RCPT command,
so that the server can apply the different policies on each of the
sender's delivery attempts. So the introduction is wrong when it says
"only legitimate way". Also, it fails to mention that the most serious
problem with emitting DSNs for policy reasons is spam backscatter. The
discussion of performance is relatively trivial in comparison.

The service extension framework needs to say how much it increases the
maximum length of a MAIL command.

The draft fails to say that the 353 response may only be issued after the
last of the message data.

What is an "absolute response code"? Is 4yz included? The text "any
response code which is valid for the RCPT TO command is valid for any
per-recipient response code" suggests that 352 is valid after data as
well as before data.

If some recpients get a 2yz response and some a 4yz response, why must the
server give a 4yz final response? This is an undesirable change - at the
moment SMTP allows a 2yz response in this situation.

The examples are not using ENHANCEDSTATUSCODES properly.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
DOVER WIGHT: VARIABLE 2, BECOMING WESTERLY 4 OR 5. SMOOTH BECOMING SLIGHT.
MAINLY FAIR. MODERATE OR GOOD.

Date: Tue, 30 Jan 2007 20:17:00 +0100
From: Keld =?iso-8859-1?Q?J=F8rn?= Simonsen <[email-masked]>
To: [email-masked]
Subject: greylisting done at end of headers, or end of daya (QUIT) ?
Sender: [email-masked]

I am applying greylisting and it really has some effects on the amount
of spam coming in.

I am running postfix with postgrey, and postgrey only has data available
from the envelope, such that Message_Id: information is not available. I
notice that in Freebsd greylisting is done using message-id:
http://www.freebsd.org/doc/en_US.ISO8859-1/articles/relaydelay/article.html

I see the follwing scenaro for me: a zombie machine sends out spam for
me, and I greylist it and the zombie does not resend the message to me. 
The the same zombie sends me another spam mail, and then this is
recognized by postgrey as the first message being resent, as it does not
know better. I have a feeling that this is going on in some amount of
cases, but I cannot investigate it as postgrey does not have access to
the info I would like to log.

So I ask you: would greylisting based on some unique id like Message-id:
lead to a better result?

And would there be problems issuing an error code like "file system full"
at the time of the "QUIT" command? I have heard that some genuine
MTAs would have problems with recovering from such a message at that
time. Which MTAs would that be?

best regards
keld

Date: Tue, 30 Jan 2007 19:18:29 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Degree of adoption for Enhanced Reply Codes?
Cc: Alexey Melnikov <[email-masked]>, Dave Crocker <[email-masked]>
Sender: [email-masked]

Dave Crocker writes:
> Alexey Melnikov wrote:
>>> I'm interested in getting a basic sense of how useful email 
>>> operators are finding the Enhanced SMTP reply codes.
>>
>> Operators or SMTP server developers?
>
> Server developers do not actually *use* reply code information.  I'm 
> interested in utility.

On the IETF lists, people all seem to talk about 5xx errors, not 5.x.x errors.

Arnt

Date: Tue, 30 Jan 2007 12:36:13 -0500
From: "Eric A. Hall" <[email-masked]>
To: [email-masked]
Subject: [Fwd: I-D ACTION:draft-hall-deferrals-00.txt]
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------000007060002030605050108
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

There has been some discussion on ASRG about an LMTP-like deferred-RCPT
model so I dusted off the old INLINE-DSN draft from 2004, cleaned it up,
and have resubmitted it.

A couple of people are looking to implement this, so there might be cause
to consider pushing this onto the standards track now.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

--------------000007060002030605050108
Content-Type: message/rfc822;
 name="I-D ACTION:draft-hall-deferrals-00.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="I-D ACTION:draft-hall-deferrals-00.txt"

To: [email-masked]
Cc: 
From: [email-masked]
Date: Mon, 29 Jan 2007 15:50:02 -0500
Subject: I-D ACTION:draft-hall-deferrals-00.txt 
Reply-To: [email-masked]
Xref: goose.ehsco.com

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title		: SMTP Service Extension for Deferred RCPT 
	Author(s)	: E. Hall
	Filename	: draft-hall-deferrals-00.txt
	Pages		: 
	Date		: 2007-1-29
	
     This memo describes a mechanism for the negotiation and transfer 
     of per-recipient notification responses in SMTP. 

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hall-deferrals-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-hall-deferrals-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-hall-deferrals-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-hall-deferrals-00.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-hall-deferrals-00.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

--NextPart--

--------------000007060002030605050108--

To: [email-masked]
Cc: [email-masked]
Subject: Re: Degree of adoption for Enhanced Reply Codes?
From: [email-masked]
Date: Tue, 30 Jan 2007 10:35:16 -0500
Sender: [email-masked]

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

On Mon, 29 Jan 2007 14:40:58 PST, Dave Crocker said:
> I'm interested in getting a basic sense of how useful email operators are 
> finding the Enhanced SMTP reply codes.

They'd be a lot more useful if certain releases of certain software programs
didn't insist on re-writing things in a manner that lost the enhanced reply code.

(Sorry for being snarky, but so far today I've already had to deal with *two*
separate issues where that happened - one caused by a popular MUA, another caused
by a popular MTA.  Blegga.)

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

--==_Exmh_1170171316_27151P--

Date: Tue, 30 Jan 2007 15:30:39 +0000
From: Tony Finch <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: Degree of adoption for Enhanced Reply Codes?
Sender: [email-masked]

On Mon, 29 Jan 2007, Dave Crocker wrote:
>
> I'm interested in getting a basic sense of how useful email operators
> are finding the Enhanced SMTP reply codes. This isn't for anything
> formal, but the question came up in discussion and I realized that I had
> no idea how widespread adoption or use was.

There was some discussion about this some months ago in the thread
starting with this post:

http://www.imc.org/ietf-smtp/mail-archive/msg02756.html

Probably the most prominent currently maintained MTA that doesn't support
them is Exim.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
ROCKALL MALIN: SOUTHWEST 6 TO GALE 8. ROUGH OR VERY ROUGH, OCCASIONALLY HIGH
LATER. OCCASIONAL RAIN. MODERATE OR GOOD.

Date: Tue, 30 Jan 2007 07:21:42 -0800
From: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: Alexey Melnikov <[email-masked]>
CC: [email-masked]
Subject: Re: Degree of adoption for Enhanced Reply Codes?
Sender: [email-masked]

Alexey Melnikov wrote:
>> I'm interested in getting a basic sense of how useful email operators 
>> are finding the Enhanced SMTP reply codes.
> 
> Operators or SMTP server developers?

Server developers do not actually *use* reply code information.  I'm interested 
in utility.

So I do mean "operators".

>> This isn't for anything formal, but the question came up in discussion 
>> and I realized that I had no idea how widespread adoption or use was.
> 
> Isode SMTP server supports them. I personally find them more useful than 
> the regular SMTP error codes, as they are more detailed.

ok.  thanks.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Tue, 30 Jan 2007 14:59:49 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: Degree of adoption for Enhanced Reply Codes?
Sender: [email-masked]

Dave Crocker wrote:

> Howdy.
>
> I'm interested in getting a basic sense of how useful email operators 
> are finding the Enhanced SMTP reply codes.

Operators or SMTP server developers?

> This isn't for anything formal, but the question came up in discussion 
> and I realized that I had no idea how widespread adoption or use was.

Isode SMTP server supports them. I personally find them more useful than 
the regular SMTP error codes, as they are more detailed.

Date: Mon, 29 Jan 2007 14:40:58 -0800
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: [email-masked]
Subject: Degree of adoption for Enhanced Reply Codes?
Sender: [email-masked]

Howdy.

I'm interested in getting a basic sense of how useful email operators are 
finding the Enhanced SMTP reply codes.

This isn't for anything formal, but the question came up in discussion and I 
realized that I had no idea how widespread adoption or use was.

Thanks.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

To: [email-masked]
From: Lisa Dusseault <[email-masked]>
Subject: Fwd: Last Call: draft-siemborski-rfc2554bis (SMTP Service Extension  for Authentication) to Proposed Standard 
Date: Wed, 24 Jan 2007 14:37:11 -0800
Sender: [email-masked]

--Apple-Mail-9-244986574
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

FYI (also POP3 authentication update was sent to Last Call)

Lisa

Begin forwarded message:

> From: The IESG <[email-masked]>
> Date: January 24, 2007 1:41:12 PM PST
> To: IETF-Announce <[email-masked]>
> Subject: Last Call: draft-siemborski-rfc2554bis (SMTP Service  
> Extension  for Authentication) to Proposed Standard
> Reply-To: [email-masked]
>
> The IESG has received a request from an individual submitter to  
> consider
> the following document:
>
> - 'SMTP Service Extension for Authentication '
>    <draft-siemborski-rfc2554bis-07.txt> as a Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to  
> the
> [email-masked] mailing lists by 2007-02-21. Exceptionally,
> comments may be sent to [email-masked] instead. In either case, please
> retain the beginning of the Subject line to allow automated sorting.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-siemborski-rfc2554bis-07.txt
>
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi? 
> command=view_id&dTag=10913&rfc_flag=0
>
>
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf-announce

--Apple-Mail-9-244986574
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=ISO-8859-1

<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; ">FYI (also POP3 authentication =
update was sent to Last Call)<DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Lisa<BR><DIV><BR><DIV>Begin =
forwarded message:</DIV><BR =
class=3D"Apple-interchange-newline"><BLOCKQUOTE type=3D"cite"><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><FONT face=3D"Helvetica" size=3D"3" color=3D"#000000" =
style=3D"font: 12.0px Helvetica; color: #000000"><B>From: =
</B></FONT><FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">The IESG &lt;<A =
href=3D"mailto:[email-masked]">[email-masked]</A>&gt;</F=
ONT></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><FONT face=3D"Helvetica" =
size=3D"3" color=3D"#000000" style=3D"font: 12.0px Helvetica; color: =
#000000"><B>Date: </B></FONT><FONT face=3D"Helvetica" size=3D"3" =
style=3D"font: 12.0px Helvetica">January 24, 2007 1:41:12 PM =
PST</FONT></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><FONT face=3D"Helvetica" =
size=3D"3" color=3D"#000000" style=3D"font: 12.0px Helvetica; color: =
#000000"><B>To: </B></FONT><FONT face=3D"Helvetica" size=3D"3" =
style=3D"font: 12.0px Helvetica">IETF-Announce &lt;<A =
href=3D"mailto:[email-masked]">[email-masked]</A>&gt;</FON=
T></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: =
0px; margin-left: 0px; "><FONT face=3D"Helvetica" size=3D"3" =
color=3D"#000000" style=3D"font: 12.0px Helvetica; color: =
#000000"><B>Subject: </B></FONT><FONT face=3D"Helvetica" size=3D"3" =
style=3D"font: 12.0px Helvetica"><B>Last Call: =
draft-siemborski-rfc2554bis (SMTP Service Extension<SPAN =
class=3D"Apple-converted-space">=A0 </SPAN>for Authentication) to =
Proposed Standard<SPAN =
class=3D"Apple-converted-space">=A0</SPAN></B></FONT></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><FONT face=3D"Helvetica" size=3D"3" color=3D"#000000" =
style=3D"font: 12.0px Helvetica; color: #000000"><B>Reply-To: =
</B></FONT><FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica"><A =
href=3D"mailto:[email-masked]">[email-masked]</A></FONT></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV> <DIV style=3D"margin-top:=
 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">The =
IESG has received a request from an individual submitter to =
consider</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">the following =
document:</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">- 'SMTP Service Extension for Authentication =
'</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: =
0px; margin-left: 0px; "><SPAN class=3D"Apple-converted-space">=A0=A0 =
</SPAN>&lt;draft-siemborski-rfc2554bis-07.txt&gt; as a Proposed =
Standard</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">The IESG plans to make a decision in the next few =
weeks, and solicits</DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; ">final comments on this =
action.<SPAN class=3D"Apple-converted-space">=A0 </SPAN>Please send =
substantive comments to the</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><A =
href=3D"mailto:[email-masked]">[email-masked]</A> mailing lists by =
2007-02-21. Exceptionally,<SPAN =
class=3D"Apple-converted-space">=A0</SPAN></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">comments =
may be sent to <A href=3D"mailto:[email-masked]">[email-masked]</A> =
instead. In either case, please<SPAN =
class=3D"Apple-converted-space">=A0</SPAN></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">retain =
the beginning of the Subject line to allow automated sorting.</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">The file =
can be obtained via</DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; "><A =
href=3D"http://www.ietf.org/internet-drafts/draft-siemborski-rfc2554bis-07=
.txt">http://www.ietf.org/internet-drafts/draft-siemborski-rfc2554bis-07.t=
xt</A></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">IESG =
discussion can be tracked via</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><A =
href=3D"https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_=
id&dTag=3D10913&rfc_flag=3D0">https://datatracker.ietf.org/public/pidtrack=
er.cgi?command=3Dview_id&amp;dTag=3D10913&amp;rfc_flag=3D0</A></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">_______________________________________________</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">IETF-Announce mailing list</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><A =
href=3D"mailto:[email-masked]">[email-masked]</A></DIV><DI=
V style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><A =
href=3D"https://www1.ietf.org/mailman/listinfo/ietf-announce">https://www1=
.ietf.org/mailman/listinfo/ietf-announce</A></DIV> =
</BLOCKQUOTE></DIV><BR></DIV></BODY></HTML>=

--Apple-Mail-9-244986574--

Date: Tue, 23 Jan 2007 09:24:03 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Frank Ellermann <[email-masked]>
CC: [email-masked]
Subject: Re: Advancing RFC2821 to Draft Standard -- outline of work
Sender: [email-masked]

Frank Ellermann wrote:
> Lisa Dusseault wrote:
> 
>> Charter-bashing should be done *early* if you disagree
> 
> However there's no way that this rest can be a "draft standard"
> without fixing another major problem in RFC 2821, the design
> flaw to favour "accept and bounce" instead of "reject".

Frank, I agree with you, but IMO, in reality this is an implementation 
dependent and local policy issue.

This requires SMTP level validation in order to provide instant 
rejection gratification and we can only justify a SMTP level validation 
in reference to today's high speed computers and enhanced scaling of 
SMTP servers.

In other words, we can't mandate "Integration and Performance 
Requirements" on SMTP developers and their customers installed operations.

There are two part:

1) A host may not be able to validate a RCPT TO. But it SHOULD be
    highly recommended if it can.  For us, we realize at least
    60% rejection rate purely on RCPT TO: rejections.  The
    harvesting red herring does not apply.

2) AVS processing may not scale well.  Note, a few months back
    I spoke with the CTO of an AVS company and we touched base
    on the ideas of dynamic SMTP vs delay post SMTP vs active (background
    process file I/O monitor) mail processing.  He was highly convinced
    that dynamic SMTP processing does not scale well and he indicated the
    abandonment of long time AVS vendors with command line scanners
    as evidence of the preferred direction.  Unfortunately, he also
    seem to be totally oblivious about the non-bouncing of accepted
    post SMTP mail rejections.

At best, we can add hindsight to encourage SMTP level validation and to 
also make it the recommended default choice for operations to use in 
their local policies.   It can probably be part of the security section.

Other points:

1) On a related note, we should "focus" and "strengthen" the idea that 
return path MUST be a valid address.  The Bounce system can only work if 
the Return Path is valid.  A growing number of systems have implemented 
MAIL FROM validation concept.  In my view, one of strongest points in 
2821 that has help tremendously in MAIL FROM validation technology is 
the following:

| 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.

This allowed us to justify the delay of MAIL FROM response until the 
RCPT TO validation was completed.  As indicated above, with a 60% RCPT 
TO rejection rate, this provided us with a matching savings of 60% MAIL 
FROM validation overhead.  The DNS overhead was drastically reduced.

2) We should also remove old school legacy statements like this:

   7.1 Mail Security and Spoofing

    ....

    This specification does not further address the authentication issues
    associated with SMTP other than to advocate that useful functionality
    not be disabled in the hope of providing some small margin of
    protection against an ignorant user who is trying to fake mail.

Its no longer a small ignorant user, but a Multi-Billion dollar industry.

3) I also think we should steer away from the term "Authentication" 
since it is more like "Message Acceptance Technology"  since acceptance 
comes in many forms.  Authentication is too heavy handed with politics, 
conflict of interest and multi-discipline conflictive subjective 
reasonings.   By thinking of terms of Message Acceptance, it allows us 
to focus on the requirements and BCP we use for accepting and/or 
rejecting mail.  For example, and I am just using this for an example, 
Message Acceptance in terms of SMTP 3.0, implies:

      Valid HELO/EHLO
      Valid MAIL FROM
      Valid RCPT TO
      Local Policy DATA acceptance

That should be the first level.

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

Date: Tue, 23 Jan 2007 00:59:11 -0500
To: [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: Advancing RFC2821 to Draft Standard -- outline of work
Sender: [email-masked]

At 17:15 -0500 on 01/22/2007, [email-masked] wrote about Re: 
Advancing RFC2821 to Draft Standard -- outline of work:

>Would tagging "accept and bounce" as a SHOULD NOT (with appropriate text
>attached) be doable without resetting back to Proposed?  I know "MUST NOT"
>would cause such a reset, and even I'm not ready to stick *that* label on
>"accept and bounce" - mostly because I've spent too much time working with
>large-scale mail systems where the mailbox *was* valid when we sent the
>far end the '250 OK', but had been race-conditioned into oblivion by the
>time actual final delivery was attempted.

IMHO, so long as you validate at receive time that the Return-Path 
(that is eventually going to end up getting used to send the Bounce 
to due to an recipient email address that was valid at receive time 
going invalid in the time span before you attempt final delivery 
situation [as you state in the above quote]) is valid and an accurate 
reflection of where the message is coming from, I do not see any 
problem with as being a SHOULD NOT but allowed with that "Valid the 
Return-Path" IF YOU SUPPORT IT caveat.

To: Frank Ellermann <[email-masked]>
Cc: [email-masked]
Subject: Re: Advancing RFC2821 to Draft Standard -- outline of work
From: [email-masked]
Date: Mon, 22 Jan 2007 17:15:50 -0500
Sender: [email-masked]

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

On Mon, 22 Jan 2007 22:24:27 +0100, Frank Ellermann said:
> However there's no way that this rest can be a "draft standard"
> without fixing another major problem in RFC 2821, the design
> flaw to favour "accept and bounce" instead of "reject".

Unfortunately, I have to agree with Frank here - today's Internet isn't
the Internet of RFC821, and we really *should* take a very close look at
fixing that language even if it *does* mean another iteration at Proposed,
beecause if we don't fix it this time around, we'll be saddled with it
for years - RFC6821 is a long way aray.

Would tagging "accept and bounce" as a SHOULD NOT (with appropriate text
attached) be doable without resetting back to Proposed?  I know "MUST NOT"
would cause such a reset, and even I'm not ready to stick *that* label on
"accept and bounce" - mostly because I've spent too much time working with
large-scale mail systems where the mailbox *was* valid when we sent the
far end the '250 OK', but had been race-conditioned into oblivion by the
time actual final delivery was attempted.

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

--==_Exmh_1169504150_17122P--

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Advancing RFC2821 to Draft Standard -- outline of work
Date:  Mon, 22 Jan 2007 22:24:27 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 43
Sender: [email-masked]

Lisa Dusseault wrote:

> Charter-bashing should be done *early* if you disagree

Okay.  Fixing the known errata and bugs - there are quite a lot -
in RFC 2821 is a good idea, and there should be no major issues
with this goal.

One of the major problems with RFC 2821 is that it's too long.

It could be an idea to extract all legacy features into a new
"history" document:  SEND, SOML, SAML, HELO, source routes,
reverse paths (excl. the cases still in use today), anything
else in appendix F (e.g. TURN), and probably more (e.g. EXPN).

After the cruft has been removed from the picture in a history
document updating RFC 2821 it will be easier to tackle the rest.

However there's no way that this rest can be a "draft standard"
without fixing another major problem in RFC 2821, the design
flaw to favour "accept and bounce" instead of "reject".

In an ideal world "try to deliver as long as there's a chance
that it works out" is a good strategy.  In the real world with a
spam ratio near 80% - and most spam uses forged reverse paths -
"in case of doubt reject a.s.a.p." is a good strategy.  And any
"accept on probation because it's always okay to bounce later"
strategy is today considered as net abuse.

I don't see how a future 2821bis can swap this fundamental - and
today known to be wrong - assumption of RFC 281, the "accept and
bounce" before "reject" axiom, and still be a "draft standard".

And what should a future 2821bis do with 3.10.1, in essence the
same as 1123 5.3.6(a) ?  It's at the core of the "forged reverse
path" issue, related to the removal of source routes in RFC 1123.

Just because RFC 2821 inherited this design flaw it's still a
design flaw, costing billions of dollars, and intentionally NOT
fixing it in a DS is a legal hazard and poor engineering.

Frank

Date: Mon, 22 Jan 2007 15:31:51 -0500
From: Tony Hansen <[email-masked]>
To: ietf-822 mailing list <[email-masked]>, [email-masked], imapext <[email-masked]>
CC: [email-masked]
Subject: [Fwd: Advancing RFC2821 to Draft Standard -- outline of work]
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------060704040600040307050804
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

This is an FYI of work that's starting up on the [email-masked]
mailing list.

	Tony Hansen
	[email-masked]

--------------060704040600040307050804
Content-Type: message/rfc822;
 name="Advancing RFC2821 to Draft Standard -- outline of work"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename*0="Advancing RFC2821 to Draft Standard -- outline of work"

To: [email-masked]
From: Lisa Dusseault <[email-masked]>
Subject: Advancing RFC2821 to Draft Standard -- outline of work
Date: Mon, 22 Jan 2007 11:40:08 -0800
Sender: [email-masked]

I've been discussing the advancement of RFC2821 along the standards  
track with a few people, and we'd like to proceed publicly.  This  
email can be considered an informal charter and plan for initial  
work, with consensus goals for the effort, which may not need a  
formal WG.  Charter-bashing should be done *early* if you disagree.  
I'd rather avoid late-cycle suggestions to change the goals. This  
list seems like a fine place to have discussions about the goals, as  
well as to do the actual work, and I'll post pointers to a couple  
other lists to direct people here who aren't already subscribed.

1.  We want to advance RFC2821/SMTP to Draft Standard.  Thus, we  
don't want to design anything "new" or "better" for SMTP as part of  
this particular effort, which would require recycling at Proposed  
Standard -- in fact, we want to be conservative in minimizing  
changes.   As with any movement from DS to PS, changes should be  
limited to, if possible: clarifications of the spec where there are  
discrepancies, and removal of unused features. The fixing of "bugs"  
should be limited to those that have a *very strong* consensus.

Tony Hansen volunteered to keep a chair-like eye on the activity,  
progress and consensus where needed, which will be particularly  
helpful as I'll be on leave in Feb and March.

2.  We do think there are some bugs in the document that are worth  
fixing.  We don't think that those fixes are likely to cause  
significant change to the behavior of conforming implementations.   
Tony Hansen put RFC2821 into XML2RFC format, and John Klensin has a  
revision with fixes which he'll post here.

Volunteers to review, please?

3.  Some interop reporting is likely needed.  We don't think this  
requires a huge effort.  Here's one way to proceed: one step is for  
somebody to write an outline that lists the major interop areas or  
features to consider.  The next step is for a couple implementors to  
fill in that outline their experience with their code-bases and  
talking to other implementations.  Another way to try to proceed is  
to have implementors report what they *don't* implement or find  
doesn't work.  We don't believe we have to document every MUST/MAY/ 
SHOULD but can look at least one level higher (less granular).   
Either way, it shouldn't require new testing, and we definitely want  
to try to keep this lightweight so that there's hope it actually gets  
done.

Ned Freed and Alexey Melnikov have volunteered to do some work here  
-- Alexey has already begun -- and Dave Crocker outlined a "interop  
questionnaire" that would be lightweight.

Ned, Alexey and Dave can you post your proposals or status to this list?

Lisa

--------------060704040600040307050804--

To: [email-masked]
From: Lisa Dusseault <[email-masked]>
Subject: Advancing RFC2821 to Draft Standard -- outline of work
Date: Mon, 22 Jan 2007 11:40:08 -0800
Sender: [email-masked]

I've been discussing the advancement of RFC2821 along the standards  
track with a few people, and we'd like to proceed publicly.  This  
email can be considered an informal charter and plan for initial  
work, with consensus goals for the effort, which may not need a  
formal WG.  Charter-bashing should be done *early* if you disagree.  
I'd rather avoid late-cycle suggestions to change the goals. This  
list seems like a fine place to have discussions about the goals, as  
well as to do the actual work, and I'll post pointers to a couple  
other lists to direct people here who aren't already subscribed.

1.  We want to advance RFC2821/SMTP to Draft Standard.  Thus, we  
don't want to design anything "new" or "better" for SMTP as part of  
this particular effort, which would require recycling at Proposed  
Standard -- in fact, we want to be conservative in minimizing  
changes.   As with any movement from DS to PS, changes should be  
limited to, if possible: clarifications of the spec where there are  
discrepancies, and removal of unused features. The fixing of "bugs"  
should be limited to those that have a *very strong* consensus.

Tony Hansen volunteered to keep a chair-like eye on the activity,  
progress and consensus where needed, which will be particularly  
helpful as I'll be on leave in Feb and March.

2.  We do think there are some bugs in the document that are worth  
fixing.  We don't think that those fixes are likely to cause  
significant change to the behavior of conforming implementations.   
Tony Hansen put RFC2821 into XML2RFC format, and John Klensin has a  
revision with fixes which he'll post here.

Volunteers to review, please?

3.  Some interop reporting is likely needed.  We don't think this  
requires a huge effort.  Here's one way to proceed: one step is for  
somebody to write an outline that lists the major interop areas or  
features to consider.  The next step is for a couple implementors to  
fill in that outline their experience with their code-bases and  
talking to other implementations.  Another way to try to proceed is  
to have implementors report what they *don't* implement or find  
doesn't work.  We don't believe we have to document every MUST/MAY/ 
SHOULD but can look at least one level higher (less granular).   
Either way, it shouldn't require new testing, and we definitely want  
to try to keep this lightweight so that there's hope it actually gets  
done.

Ned Freed and Alexey Melnikov have volunteered to do some work here  
-- Alexey has already begun -- and Dave Crocker outlined a "interop  
questionnaire" that would be lightweight.

Ned, Alexey and Dave can you post your proposals or status to this list?

Lisa

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: [Fwd: I-D ACTION:draft-levine-smtp-batv-00.txt]
Date:  Fri, 12 Jan 2007 00:36:21 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 10
Sender: [email-masked]

Dave Crocker wrote:
 
> <http://mipassoc.org/batv/>

The I-D claims to be a MARID draft, do you really want 
this, with a "see also [[MARID]]" in Wikipedia's BATV
article ?  Or was it only an old boilerplate ?

Frank

Date: Thu, 11 Jan 2007 13:26:38 -0800
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: "[email-masked]" <[email-masked]>
Subject: [Fwd: I-D ACTION:draft-levine-smtp-batv-00.txt]
Sender: [email-masked]

An html version is also available on the BATV web page:

    <http://mipassoc.org/batv/>

d/

-------- Original Message --------
Subject: I-D ACTION:draft-levine-smtp-batv-00.txt
Date: Thu, 11 Jan 2007 15:50:02 -0500
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: Bounce Address Tag Validation (BATV)
	Author(s)	: J. Levine, et al.
	Filename	: draft-levine-smtp-batv-00.txt
	Pages		: 14
	Date		: 2007-1-11
	
    The envelope of Internet mail contains an RFC2821.MailFrom command,
    which may supply an address to be used as the recipient of
    transmission and delivery notices about the original message.
    Existing Internet mail permits unauthorized use of addresses in the
    MailFrom command, causing notices to be sent to unwitting and
    unwilling recipients.  Bounce Address Tag Validation (BATV) defines
    an extensible mechanism for validating the MailFrom address.  It also
    defines an initial use of that mechanism which requires no
    administrative overhead and no global implementation.

    This document is a revision of draft-levine-mass-batv-02.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-levine-smtp-batv-00.txt

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: [Fwd: Last Call: draft-ietf-opes-smtp-security (Integrity, privacy and security in OPES for SMTP) to Informational RFC]
Date:  Sat, 06 Jan 2007 22:11:36 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 18
Cc: [email-masked]
Sender: [email-masked]

Tony Hansen wrote on <ietf-822.imc.org>

> fyi, this seems relevant to these two lists.

Thanks, answered on the general list, forwarding your pointer
to the ASRG list.  Maybe I simply don't get it, or the I-D
proposes to send special NDRs for mails considered as dubious
by OPES, and the "special" feature is a way to bypass OPES on
behalf of the (alleged) sender in another mail.

That would be a convoluted kind of challenge response system,
and the discussion of this known 2821 issue in the draft does
not justify this net abuse.

> http://www.ietf.org/internet-drafts/draft-ietf-opes-smtp-security-02.txt

Frank

Date: Tue, 02 Jan 2007 18:54:37 -0500
From: Tony Hansen <[email-masked]>
To: ietf-822 mailing list <[email-masked]>, SMTP Interest Group <[email-masked]>
Subject: [Fwd: Last Call: draft-ietf-opes-smtp-security (Integrity, privacy and security in OPES for SMTP) to Informational RFC]
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------010905040309040200000201
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

fyi, this seems relevant to these two lists.

	Tony

--------------010905040309040200000201
Content-Type: message/rfc822;
 name*0="Last Call: draft-ietf-opes-smtp-security (Integrity, privacy  an";
 name*1="d security in OPES for SMTP) to Informational RFC"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename*0="Last Call: draft-ietf-opes-smtp-security (Integrity, privacy";
 filename*1="  and security in OPES for SMTP) to Informational RFC"

To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Date: Tue, 02 Jan 2007 09:44:23 -0500
Cc: [email-masked]
Subject: Last Call: draft-ietf-opes-smtp-security (Integrity, privacy 
 and security in OPES for SMTP) to Informational RFC 
Reply-To: [email-masked]

The IESG has received a request from the Open Pluggable Edge Services WG
(opes) to consider the following document:

- 'Integrity, privacy and security in OPES for SMTP '
   <draft-ietf-opes-smtp-security-02.txt> as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2007-01-17. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-opes-smtp-security-02.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14690&rfc_flag=0

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf-announce

--------------010905040309040200000201--