Subject: Re: draft-klensin-rfc2821bis-04: VRFY and EXPN syntax
From: SM <[email-masked]>
To: "Peter J. Holzer" <[email-masked]>, [email-masked]
Date: Mon, 30 Jul 2007 09:08:16 -0700
List-Id: <ietf-smtp.imc.org>

Hi Peter,
At 13:00 19-07-2007, Peter J. Holzer wrote:
> > No, local mailboxes does not refer to the local part of the address
> > only.  A host may handle mail for more than one domain.
>
>In practice, yes. I am talking about the assumed intention of the author
>here. Of course I don't *know* what they intended, but:
>
>|  MUST include at least
>|  recognition of local mailboxes as "user names".  However, since
>|  current Internet practice often results in a single host handling
>|  mail for multiple domains, hosts, especially hosts that provide this
>|  functionality, SHOULD accept the "local-part@domain" form as a "user
>|  name
>
>sounds to me very much as if the authors saw a contrast between "local
>mailbox" and "local-part@domain". Otherwise, why would the second
>sentence start with "however"? And why is it there at all if it was
>already stated earlier that a mailbox is identified by an address of the
>form "local-part@domain"? The phrase "user name and domain" earlier in
>the section strengthens that impression.

That's a special case where a single host handles mail for multiple 
domains.  The "local-part@domain" can be considered as a "user name" 
in such a situation.

> >
> > In this example:
> >
> >        C: VRFY <[email-masked]>
> >        S: 250 smith <[email-masked]>
> >
> > the mailbox is [email-masked].
>
>Yes, of course. What are you trying to say?

That was an example to show that local mailbox may be more than the local-part.

>I think the current RFC is rather clear that pointed brackets are not
>required. An implementation may accept them, but it may not require
>them. I know that implemenations exist which do require them but I think
>they are very rare and am willing to treat that as a bug and would
>rather not include it into the RFC. VRFY is already enough of a mess.

I used pointed brackets in my examples.  Should they be removed?

Regards,
-sm 

Date: Thu, 26 Jul 2007 00:22:28 -0400
From: Tony Hansen <[email-masked]>
To: ietf-822 mailing list <[email-masked]>
CC: SMTP Interest Group <[email-masked]>, LEMONADE WG <[email-masked]>, IMAP extensions mailing list <[email-masked]>, EAI WG <[email-masked]>, POP3 extensions mailing list <[email-masked]>, USEFOR WG <[email-masked]>, SIMPLE WG <[email-masked]>
Subject: Mailing List Last Call for 2822 update internet-draft
Sender: [email-masked]

There have been some comments on draft-resnick-2822upd-* but they have
dwindled down to none.

This is a "formal" Mailing List Last Call on
draft-resnick-2822upd-02.txt. The last call will last for two weeks
time, ending on August 10, 2007.

The document will be discussed on the 822 mailing list,
<[email-masked]>. Please send your comments there.

For a copy of the current draft, you can find it at

	http://www.ietf.org/internet-drafts/draft-resnick-2822upd-02.txt
or
	http://tools.ietf.org/html/draft-resnick-2822upd

Depending on the outcome of the Mailing List Last Call, the next step
will be to submit the document (or its revision) to the IESG for
IETF-wide Last Call.

Thanks!

	Tony Hansen
	[email-masked]

Date: Wed, 25 Jul 2007 09:47:27 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: [Fwd: I-D Action:draft-hansen-4468upd-mailesc-registry-02.txt]
Cc: Tony Hansen <[email-masked]>, Alexey Melnikov <[email-masked]>, Chris Newman <[email-masked]>
Sender: [email-masked]

Alexey Melnikov writes:
> Chris Newman wrote:
> [...]
>
>> This approach does not alter:
>> <http://www.ietf.org/internet-drafts/draft-siemborski-rfc2554bis-09.txt>
>> which is in the RFC editor queue.
>
> BTW, this is RFC 4954 now.

It is? Then I repeat my prediction: SASL-IR will be RFC 5000.

Arnt

Date: Wed, 25 Jul 2007 02:39:36 +0100
From: Alexey Melnikov <[email-masked]>
To: Chris Newman <[email-masked]>
CC: Tony Hansen <[email-masked]>, [email-masked]
Subject: Re: [Fwd: I-D Action:draft-hansen-4468upd-mailesc-registry-02.txt]
Sender: [email-masked]

Chris Newman wrote:
 [...]

> This approach does not alter:
> <http://www.ietf.org/internet-drafts/draft-siemborski-rfc2554bis-09.txt>
> which is in the RFC editor queue.

BTW, this is RFC 4954 now.

> One other question: do we want to list one or more non-extended SMTP 
> codes that are typically used with an extended code in the registry?

Speaking as an implementor, I think this would be a really good idea.

From: [email-masked]
Cc: Tony Hansen <[email-masked]>, [email-masked]
Date: Tue, 24 Jul 2007 09:19:51 -0700 (PDT)
Subject: Re: [Fwd: I-D Action:draft-hansen-4468upd-mailesc-registry-02.txt]
To: Chris Newman <[email-masked]>
Sender: [email-masked]

> The conflicting uses of X.7.8 are in response to two different SMTP commands.
> As a result, there is no interoperability problem in practice.  The "auth
> invalid" only occurs in response to the "AUTH" command, and the "trust
> relationship required" only occurs in response to the "BURL" command.

> As there is no interoperability problem to fix, the goals are to document the
> meaning clearly and minimize changes to deployed code.  We have to create 1 new
> code to make the meaning clear, but we don't have to create 2 codes and
> shouldn't if we want to minimize changes in deployed code.  As X.7.8 appears to
> have more AUTH deployment than BURL deployment, I suggest deleting X.7.15 from
> this draft and changing X.7.8 and X.7.14 to say:

>    X.7.8 Authentication credentials invalid
>       Authentication failed due to invalid or insufficient
>       authentication credentials.  When this code is seen in response to the
>       Submit BURL command [RFC4468], it is synonymous with code X.7.14.
>       Defined by RFC XXXX.  Registered by IESG.

>    X.7.14 Trust relationship required
>       The submission server requires a configured trust relationship
>       with a third-party server in order to access the message content.
>       This value replaces the prior use of X.7.8 for this error
>       condition, thereby updating [RFC4468].
>       Defined by RFC XXXX.  Registered by IESG.

> This approach does not alter:
>  <http://www.ietf.org/internet-drafts/draft-siemborski-rfc2554bis-09.txt>
> which is in the RFC editor queue.

> One other question: do we want to list one or more non-extended SMTP codes that
> are typically used with an extended code in the registry?

It definitely would be a useful thing to have in the registry.

				Ned			

Date: Tue, 24 Jul 2007 08:07:18 -0500
From: Chris Newman <[email-masked]>
Subject: Re: [Fwd: I-D Action:draft-hansen-4468upd-mailesc-registry-02.txt]
To: Tony Hansen <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

The conflicting uses of X.7.8 are in response to two different SMTP commands. 
As a result, there is no interoperability problem in practice.  The "auth 
invalid" only occurs in response to the "AUTH" command, and the "trust 
relationship required" only occurs in response to the "BURL" command.

As there is no interoperability problem to fix, the goals are to document the 
meaning clearly and minimize changes to deployed code.  We have to create 1 new 
code to make the meaning clear, but we don't have to create 2 codes and 
shouldn't if we want to minimize changes in deployed code.  As X.7.8 appears to 
have more AUTH deployment than BURL deployment, I suggest deleting X.7.15 from 
this draft and changing X.7.8 and X.7.14 to say:

   X.7.8 Authentication credentials invalid
      Authentication failed due to invalid or insufficient
      authentication credentials.  When this code is seen in response to the
      Submit BURL command [RFC4468], it is synonymous with code X.7.14.
      Defined by RFC XXXX.  Registered by IESG.

   X.7.14 Trust relationship required
      The submission server requires a configured trust relationship
      with a third-party server in order to access the message content.
      This value replaces the prior use of X.7.8 for this error
      condition, thereby updating [RFC4468].
      Defined by RFC XXXX.  Registered by IESG.

This approach does not alter:
 <http://www.ietf.org/internet-drafts/draft-siemborski-rfc2554bis-09.txt>
which is in the RFC editor queue.

One other question: do we want to list one or more non-extended SMTP codes that 
are typically used with an extended code in the registry?

                - Chris

Date: Thu, 19 Jul 2007 18:28:57 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: "Robert A. Rosenberg" <[email-masked]>
CC: IETF SMTP <[email-masked]>
Subject: Re: acceptings particularly a message (3)
Sender: [email-masked]

Robert A. Rosenberg wrote:
> 
> At 11:36 -0700 on 07/17/2007, Ned Freed wrote about Re: acceptings 
> particularly a message (3):
> 
>> A significant number of list managers that receive an 
 >> authoritative indication that an entire group of
 >> addresses they just tried to send to are bad are going to
>> unsubscribe them all right away rather than wait for 
 >> a later probe to confirm that the addresses are bogus.
> 
> If they are going to want to unsubscribe all the addresses, IMO, they 
> should first sanity check the list by either doing an immediate probe to 
> that list of addresses (and unsubscribe based on the results, thus not 
> unsubscribing the good addresses), or doing individual resends of the 
> message but this time sending one copy per address (in effect doing the 
> same thing as the probe and/or acting as if each address was the only 
> one at that domain/MX).

I believe what Ned as implying was that this "probe" was already done by 
virtue of the SMTP attempt to deliver the distribution and its recorded 
HARD FAILURE to deliver the mail to the address and/or domain provides 
dynamic, immediate and SMTP level feedback to the MLS (Mail List Server) 
or any one other client.

The next time the MLS connects to its smart host (or embedded SMTP 
server) to begin a distribution, it will get some 45x/55x for some of 
the RCPT TO addresses based on the SMTP recorded history for the 
address/domain.  At that point, the MLS will automatically unsubscribe 
or de-activate the address.

This works because most, if not all, good SMTP servers today will record 
HARD FAILURES for relays and will have keep a history of the bad 
addresses.  The next time an attempt is made to relay mail to the 
address, it will issue a negative response.  Why accept an RCPT TO when 
the SMTP server knows the address is bad and can't be routed?

For our MLS system, it makes the account in-active rather than 
unsubscribe. That gives someone a chance to make any individual 
corrections and reactivate the account.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Thu, 19 Jul 2007 15:54:18 -0400
To: IETF SMTP <[email-masked]>
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: acceptings particularly a message (3)
Sender: [email-masked]

At 11:36 -0700 on 07/17/2007, Ned Freed wrote about Re: acceptings 
particularly a message (3):

>A significant
>number of list managers that receive an authoritative indication 
>that an entire
>group of  addresses they just tried to send to are bad are going to 
>unsubscribe
>them all right away rather than wait for a later probe to confirm that the
>addresses are bogus.

If they are going to want to unsubscribe all the addresses, IMO, they 
should first sanity check the list by either doing an immediate probe 
to that list of addresses (and unsubscribe based on the results, thus 
not unsubscribing the good addresses), or doing individual resends of 
the message but this time sending one copy per address (in effect 
doing the same thing as the probe and/or acting as if each address 
was the only one at that domain/MX).

Date: Thu, 19 Jul 2007 16:42:08 -0400
From: John C Klensin <[email-masked]>
To: "Peter J. Holzer" <[email-masked]>, [email-masked]
Subject: Re: draft-klensin-rfc2821bis-04: VRFY and EXPN syntax
Sender: [email-masked]

--On Thursday, 19 July, 2007 22:12 +0200 "Peter J. Holzer"
<[email-masked]> wrote:

> On 2007-07-15 15:08:05 -0400, John C Klensin wrote:
>> That said, I could see doing something else if there was
>> general  consensus that it would be worthwhile.  Partially
>> because of the  circumlocutions and security consideration
>> issues, there is a  lot of text about VRFY and EXPN in
>> 2821bis.  I may regret saying  this but, without looking at
>> the spec, I think I could separate  that material out into a
>> separate document called "SMTP VRFY and  EXPN Commands" or
>> words to that effect.
> 
> I may have overlooked something, but AFAICS the descriptions
> of VRFY and EXPN take about 5 pages out of 95. We would need
> to keep a page or so for the syntax and basic functionality
> description, so we save about 4 % of the total length at the
> risk of introducing inconsistencies between the basics in
> 2821bis and the details in the separate RFC. Doesn't seem
> worthwhile to me.

I agree, but, given where the discussion seemed to be headed at
that point, felt obligated to mention the option.

     john

Date: Thu, 19 Jul 2007 22:12:34 +0200
From: "Peter J. Holzer" <[email-masked]>
To: [email-masked]
Subject: Re: draft-klensin-rfc2821bis-04: VRFY and EXPN syntax
Mail-Followup-To: [email-masked]
Sender: [email-masked]

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

On 2007-07-15 15:08:05 -0400, John C Klensin wrote:
> That said, I could see doing something else if there was general=20
> consensus that it would be worthwhile.  Partially because of the=20
> circumlocutions and security consideration issues, there is a=20
> lot of text about VRFY and EXPN in 2821bis.  I may regret saying=20
> this but, without looking at the spec, I think I could separate=20
> that material out into a separate document called "SMTP VRFY and=20
> EXPN Commands" or words to that effect.

I may have overlooked something, but AFAICS the descriptions of VRFY and
EXPN take about 5 pages out of 95. We would need to keep a page or so
for the syntax and basic functionality description, so we save about 4 %
of the total length at the risk of introducing inconsistencies between
the basics in 2821bis and the details in the separate RFC. Doesn't seem
worthwhile to me.

	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"

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

--NGIwU0kFl1Z1A3An--

Date: Thu, 19 Jul 2007 22:00:40 +0200
From: "Peter J. Holzer" <[email-masked]>
To: [email-masked]
Subject: Re: draft-klensin-rfc2821bis-04: VRFY and EXPN syntax
Mail-Followup-To: [email-masked]
Sender: [email-masked]

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

On 2007-07-16 10:04:28 -0700, SM wrote:
> At 00:46 16-07-2007, Peter J. Holzer wrote:
> >|   For the VRFY command, the string is a user name or a user name and
> >|   domain (see below).  If a normal (i.e., 250) response is returned,
> >|   the response MAY include the full name of the user and MUST include
> >|   the mailbox of the user.  It MUST be in either of the following
> >|   forms:
> >
> >
> >But that snippet indicates that the notion what a "user name" is changed
> >during the preparation of RFC 2821: "user name and domain" just doesn't
> >make sense when the user name already includes the domain.
>=20
> Yes.  It would be better if the text was more straight-forward.  But=20
> it may be too big a change as you mentioned in a previous email.

I think expressing the same meaning in clearer, more straight-forward
text should not be a problem. What we can't do is change semantics,
except where that change reflects current practice and then only very
cautiously. And this of course means that in rephrasing a requirement,
one has to be very careful not to change it. This is why I pointed out
below that I have "probably changed the intended meaning a bit". So that
others could comment on whether there is a change at all and if so,
whether it matters. (I think it doesn't matter, otherwise I wouldn't
have proposed that wording)

> >Also the description of the string argument is split into 3 paragraphs
> >with different material between, which makes it a bit hard to follow.
> >Maybe the whole section should be rearranged:
> >
> >
> >   SMTP provides commands to verify a address or obtain the content of
> >   a mailing list.  This is done with the VRFY and EXPN commands, which
> >   have character string arguments.  Implementations SHOULD support VRFY
> >   and EXPN (however, see Section 3.5.2 and Section 7.3).
> >
> >   The string argument is used to identify a user, a mailbox or a
> >   mailing-list.  An implementation of the VRFY or EXPN commands MUST at
> >   least recognize the exact names of local mailboxes in the standard
> >   "local-part@domain" format (see Section 2.3.11).  Hosts MAY also
> >   choose to recognize other strings, for example the mailbox address
> >   enclosed in angle brackets, the local part of an address or a
> >   substring of the full name of the user owning the mailbox.
>=20
> That changes the meaning somewhat as the string now identifies one=20
> user or one mailbox.  Quoting draft-04:
>=20
>    "When a name that is the argument to VRFY could identify more than one
>    mailbox, the server MAY either note the ambiguity or identify the
>    alternatives."
>=20
> Although your text is clearer, it changes the above.

I don't think it does. "The string argument is used to identify a user,
a mailbox or a mailing-list" covers the successful case, i.e., a 250
response. The paragraph you quoted covers a 553 response i.e., a special
case of of failure.=20

> Stepping back, VRFY is there to verify a "user name" and is useful for
> debugging.  The response may identify the alternative mailboxes if
> there is no exact match.

Yes, it may. I think it shouldn't (at least not to unauthenticated
users), but that's a policy decision and belongs into the section about
security considerations. I don't think my reformulation changed anything
in this respect.

> >I've eliminated the term "user name", because strictly speaking that
> >relates only to VRFY, not to EXPN. I have also probably changed the
> >intended meaning a bit: I think "local mailbox" was intended to refer
> >only to the local part of the address (otherwise "local-part@domain
> >SHOULD be recognized" makes no sense) but that contradicts section
> >2.3.11, which states that a mailbox is identified by an address of the
> >form local-part@domain. So to be consistent I've made that form
> >compulsory and listed "local part only" as one of the optional other
> >forms.
>=20
> No, local mailboxes does not refer to the local part of the address=20
> only.  A host may handle mail for more than one domain.

In practice, yes. I am talking about the assumed intention of the author
here. Of course I don't *know* what they intended, but:

|  MUST include at least
|  recognition of local mailboxes as "user names".  However, since
|  current Internet practice often results in a single host handling
|  mail for multiple domains, hosts, especially hosts that provide this
|  functionality, SHOULD accept the "local-part@domain" form as a "user
|  name

sounds to me very much as if the authors saw a contrast between "local
mailbox" and "local-part@domain". Otherwise, why would the second
sentence start with "however"? And why is it there at all if it was
already stated earlier that a mailbox is identified by an address of the
form "local-part@domain"? The phrase "user name and domain" earlier in
the section strengthens that impression.

I don't want to step on the toes of John as the editor and other the
contributors of RFC 2821. I know how hard it is to arrive at clear and
consistent formulations, especially if you are rewriting an existing
document and get lots of input from different people with a slightly
different nomenclature. But section 3.5 leaves very much the impression
that it was extended sentence by sentence from what was in RFC 821, and
while each new sentence made perfect sense the whole thing became a bit
inconsistent.

> We may have local-part@domain returning more than one possibility.

Yes, but I don't see what this has to do with my point (and in any case
I'd regard an implementation where this cannot be turned off as of very
low quality).

>  All this may sound ambiguous when compared with the other sections of
>  the RFC.
>=20
> In this example:
>=20
>        C: VRFY <[email-masked]>
>        S: 250 smith <[email-masked]>
>=20
> the mailbox is [email-masked].

Yes, of course. What are you trying to say?

> >Hmm. I'd prefer it if the RFC clearly specified one specific format
> >which must be recognized. If some implementations require the user name
> >to be enclosed in angle brackets and some require it not to be enclosed
> >in angle brackets the client needs to try both. See above for an
> >alternate clarification which makes the address without angle brackets
> >mandatory and with angle brackets optional, which is closer to my
> >understanding of the current RFC.
>=20
> I'd prefer that too.  But it may not be possible if it affects=20
> existing implementations.

I think the current RFC is rather clear that pointed brackets are not
required. An implementation may accept them, but it may not require
them. I know that implemenations exist which do require them but I think
they are very rare and am willing to treat that as a bug and would
rather not include it into the RFC. VRFY is already enough of a mess.

	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"

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

--KuLpqunXa7jZSBt+--

Date: Thu, 19 Jul 2007 20:52:05 +0200
From: "Peter J. Holzer" <[email-masked]>
To: [email-masked]
Subject: Re: draft-klensin-rfc2821bis-04: VRFY and EXPN syntax
Mail-Followup-To: [email-masked]
Sender: [email-masked]

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

On 2007-07-16 10:56:13 -0700, SM wrote:
> At 01:15 16-07-2007, Peter J. Holzer wrote:
> >Speaking of local mailboxes and user names, I think it is extremely
> >inadvisable to let VRFY return a list of real addresses on a partial
> >match. If "VRFY john" returns a list of all addresses of users whose
> >first or last name is John, it is simple to harvest addresses.
>=20
> That would only be a problem if VRFY is not restricted.  Section=20
> 3.5.2 states that VRFY is not required to work across=20
> relays.  Section 3.5 is about commands for debugging=20
> addresses.  There is already a warning about disabling these commands=20
> for security reasons.

I know. My intent is that security considerations should guide
implementors toward in an implementation which does not need to be
restricted.=20

If I as an admin, have an implementation of VRFY which returns a list of
valid addresses in a 553 response, I have to turn it off. However, if I
have an implementation which returns a 250 response only on an *exact*
match of a valid email address and returns a 550 response in all other
cases, I have no qualms of leaving it enabled. If someone wants to test
the validity of an address I'd prefer they use VRFY rather than RCPT.

Now, if the implementations lets me configure something like "exact
matches for everyone, search by full name for authenticated users and
arbitrary wild card search for the admin" that's nice. But the baseline
should be an implementation of VRFY which can be safely enabled on the
internet and reveal no more information than RCPT does on a
well-configured system.

> "In many cases, RCPT commands can be used to obtain the same=20
> information about address validity."

Yes. This is how it should be.

	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"

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

--bjuZg6miEcdLYP6q--

Date: Thu, 19 Jul 2007 13:50:09 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Dilyan Palauzov <[email-masked]>
CC: "Mark E. Mallett" <[email-masked]>, IETF SMTP <[email-masked]>
Subject: Re: acceptings partically a message (3)
Sender: [email-masked]

Dilyan Palauzov wrote:
> 
> 
>   I am now convinced, that sending
>     550 The mail was received by everybody, except <[email-masked]>
>   is definitely the wrong way.

Just think in terms of automation for computers and not HUMANS.  The 
DATA response has a special STANDARD meaning that applies to the entire 
transaction.

If you wanted to get across some special "HUMAN" interpretation, then I 
don't see a particular issue with this:

     250 Message accepted. However 1 used will failed.

then your server can send a SPECIAL DSN (NOT A BOUNCE CONCEPT) to the 
return path with a special comment using this as a template:

     --------------- CUT HERE -------------
     FROM: [email-masked]
     TO: {$SENDER}
     SUBJECT: [Trace Report] Transaction #{$MID}

     Your transaction:

       SENDER:  {$SENDER}
       FROM: {$FROM}
       DATE"  {$DATE}

     For Receipients:

      {$LIST.RCPT}

     was delivered to all except:

      {$LIST.RCPT.EXCEPTIONS}
     --------------- CUT HERE -------------

So its more of a TRACE REPORT rather than a BOUNCE report.

This would be more of a implementation concept. Not a standard 
consideration. It might be implemented as a way to send a Mail List 
Server (MLS) a special message to de-activate a failed subscriber that 
was detected at the submission level, not after some route attempt.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

From: "Mark E. Mallett" <[email-masked]>
Date: Thu, 19 Jul 2007 10:39:27 -0400
To: Dilyan Palauzov <[email-masked]>
Cc: "Mark E. Mallett" <[email-masked]>, IETF SMTP <[email-masked]>
Subject: Re: acceptings partically a message (3)
Sender: [email-masked]

On Thu, Jul 19, 2007 at 04:09:24PM +0200, Dilyan Palauzov wrote:
> 
> Hello,
> 
> >>http://www.exim.org/mail-archives/exim-users/Week-of-Mon-20070716/msg00086.html
> >
> >hmm, 404 for me.. (tried it twice in case of cut'n'paste error)
> >
> 
> This worked yesterday. The link for today is
>   http://lists.exim.org/lurker/list/exim-users.html -> "Vista  
> Mail"/Chris Edwards
> 
> ( http://lists.exim.org/lurker/thread/20070719.104051.de63af60.en.html  
> might also work).

Thanks, yep.  And I gotta say, at first glance that 'lurker' interface looks
pretty spiffy.

mm

Date: Thu, 19 Jul 2007 16:09:24 +0200
From: Dilyan Palauzov <[email-masked]>
To: "Mark E. Mallett" <[email-masked]>
Cc: IETF SMTP <[email-masked]>
Subject: Re: acceptings partically a message (3)
Sender: [email-masked]

Hello,

>> http://www.exim.org/mail-archives/exim-users/Week-of-Mon-20070716/msg00086.html
>
> hmm, 404 for me.. (tried it twice in case of cut'n'paste error)
>

This worked yesterday. The link for today is
   http://lists.exim.org/lurker/list/exim-users.html -> "Vista  
Mail"/Chris Edwards

( http://lists.exim.org/lurker/thread/20070719.104051.de63af60.en.html  
might also work).

   I am now convinced, that sending
     550 The mail was received by everybody, except <[email-masked]>
   is definitely the wrong way.

   Greetings,
     Dilian

From: "Mark E. Mallett" <[email-masked]>
Date: Thu, 19 Jul 2007 09:51:47 -0400
To: IETF SMTP <[email-masked]>
Subject: Re: acceptings partically a message (3)
Sender: [email-masked]

On Wed, Jul 18, 2007 at 09:35:52PM +0100, Tony Finch wrote:
> 
> On Wed, 18 Jul 2007, Hector Santos wrote:
> >
> > Do you have an references or links to these reports or keywords to search on?
> 
> http://www.exim.org/mail-archives/exim-users/Week-of-Mon-20070716/msg00086.html

hmm, 404 for me.. (tried it twice in case of cut'n'paste error)

mm

Date: Wed, 18 Jul 2007 18:21:32 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Tony Finch <[email-masked]>
CC: IETF SMTP <[email-masked]>
Subject: Re: acceptings partically a message (3)
Sender: [email-masked]

Tony Finch wrote:
> On Wed, 18 Jul 2007, Hector Santos wrote:
>> Do you have an references or links to these reports or keywords to search on?
> 
> http://www.exim.org/mail-archives/exim-users/Week-of-Mon-20070716/msg00086.html
> 
> Other related behaviours I have seen on my own systems by other MUAs
> include retrying the same message frequently and indefinitely in response
> to a 550 error.
> 
> Tony.

Thanks Tony.

I have a hard time believing that Microsoft will intentionally and by 
new design violate SMTP 2821 and a key conceptual email transaction 
operations.

I would suggest/ask Adam (OP) to produce a VISTA SMTP client session log 
or collect one at the EXIM server to see the full conversation.  But it 
sounds this is something beyond normal 2821 operations.

I have Windows Server 2008 Beta (AKA Longhorn, AKA Vista) on a 
multi-boot. Maybe I will try it later to see what its client does.

Just consider the repercussions of such a action. If this is true, I for 
one, will definitely contact Microsoft Exchange engineering management 
pronto.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Wed, 18 Jul 2007 13:52:17 -0700
To: IETF SMTP <[email-masked]>
From: SM <[email-masked]>
Subject: Re: acceptings partically a message (3)
Sender: [email-masked]

At 12:26 18-07-2007, Tony Finch wrote:
>I've heard reports that Windows Vista Mail ignores 550 replies it receives
>after sending the message.

There is an antivirus software that can cause such behavior as well 
when it is set to scan outgoing mail.  MS Outlook would mark the mail 
as "sent".

Regards,
-sm  

Date: Wed, 18 Jul 2007 21:35:52 +0100
From: Tony Finch <[email-masked]>
To: Hector Santos <[email-masked]>
cc: IETF SMTP <[email-masked]>
Subject: Re: acceptings partically a message (3)
Sender: [email-masked]

On Wed, 18 Jul 2007, Hector Santos wrote:
>
> Do you have an references or links to these reports or keywords to search on?

http://www.exim.org/mail-archives/exim-users/Week-of-Mon-20070716/msg00086.html

Other related behaviours I have seen on my own systems by other MUAs
include retrying the same message frequently and indefinitely in response
to a 550 error.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
IRISH SEA: SOUTHERLY, BACKING NORTHEASTERLY FOR A TIME, 3 OR 4. SLIGHT OR
MODERATE. SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.

Date: Wed, 18 Jul 2007 16:24:44 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Tony Finch <[email-masked]>
CC: Ned Freed <[email-masked]>, IETF SMTP <[email-masked]>
Subject: Re: acceptings partically a message (3)
Sender: [email-masked]

Tony Finch wrote:
> On Tue, 17 Jul 2007, Ned Freed wrote:
>> In fact there are plenty of cases where submissions intentionally accept
>> messages they know are undeliverable just so they can send back a DSN
>> later. (We routinely have customers set things up this way.) The usual
>> reason for this is to work around incompetent clients that fail to
>> display error messages correctly or consistently. (Such clients are, sad
>> to say, fairly common in some places.)
> 
> I've heard reports that Windows Vista Mail ignores 550 replies it receives
> after sending the message.

Hi Tony,

Can you elaborate on this? Do you mean its marks the TRANSACTION as 
sent? even of the DATA response is 550?   I hope that is not the case.

Do you have an references or links to these reports or keywords to 
search on? I googled the phrase (without quotes), Windows Vista Mail 
ignores 550 replies, and I didn't see anything that stood out.

Tony, you are a well respected person in the community. People "listen" 
to you. It serves us well if you have any references to this report.

Thanks.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Wed, 18 Jul 2007 12:39:39 -0700
To: SMTP Discussion <[email-masked]>
From: SM <[email-masked]>
Subject: Re: acceptings partically a message (3)
Sender: [email-masked]

At 16:59 17-07-2007, Bill McQuillan wrote:
>I believe that the first mention of DSNs above should have said:
>
>    A DSN may be sent by server.example.com to _the original message's
>    bounce address on behalf of_ both recipients.
>
>I don't believe that an MTA would send a Delivery Status Notification to
>_recipients_ that it has determined should not get the original message!

Yes, you are right.  A DSN would be sent to the address in the 
Return-Path to notify the "sender" of the delivery status.

Regards,
-sm 

Date: Wed, 18 Jul 2007 20:26:16 +0100
From: Tony Finch <[email-masked]>
To: Ned Freed <[email-masked]>
cc: IETF SMTP <[email-masked]>
Subject: Re: acceptings partically a message (3)
Sender: [email-masked]

On Tue, 17 Jul 2007, Ned Freed wrote:
>
> In fact there are plenty of cases where submissions intentionally accept
> messages they know are undeliverable just so they can send back a DSN
> later. (We routinely have customers set things up this way.) The usual
> reason for this is to work around incompetent clients that fail to
> display error messages correctly or consistently. (Such clients are, sad
> to say, fairly common in some places.)

I've heard reports that Windows Vista Mail ignores 550 replies it receives
after sending the message.

> It depends on when the error is detected. If the error is detected during
> initial submission the user agent typically throws up a window containing
> whatever message the server put out. (But not always - see above.)

The error message is frequently truncated by the MUA (one line of a
multi-line reply), or error replies to early commands are ignored in
favour of later ones, which are often along the lines of "503 Bad sequence
of commands" and therefore unhelpful to the user.

Grr.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
IRISH SEA: SOUTHERLY, BACKING NORTHEASTERLY FOR A TIME, 3 OR 4. SLIGHT OR
MODERATE. SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.

Date: Tue, 17 Jul 2007 16:59:21 -0700
From: Bill McQuillan <[email-masked]>
To: SMTP Discussion <[email-masked]>
Subject: Re: acceptings partically a message (3)
Sender: [email-masked]

I think I see a (tangential) miscommunication in this thread.

On Tue, 2007-07-17, SM wrote:

> At 10:22 17-07-2007, Dilyan Palauzov wrote:
>>Let's limit us now on hosts, that do not offer PRDR.
>>
>>** 550 Mail for [email-masked] rejected **
>>
>> > The 550 code means that mail to the above-mentioned recipients 
>> ([email-masked] and
>> > [email-masked] was rejected for policy reasons. A DSN 
>> may be sent by server.example.com
>> > to both recipients. The recipients may not see your reject 
>> message or they may not understand it.
>>
>>Is there any software nowadays, that sends DSN to the recipients 
>>telling them that they cannot receive emails?

> Some MTAs still send DSNs to the recipients to inform them that their 
> email could not be delivered.  For example, if this email is not 
> accepted by the mail server that operates this mailing list, I will 
> get a DSN from my mail server.

I believe that the first mention of DSNs above should have said:

   A DSN may be sent by server.example.com to _the original message's
   bounce address on behalf of_ both recipients.

I don't believe that an MTA would send a Delivery Status Notification to
_recipients_ that it has determined should not get the original message!

I don't think that this materially affects this discussion but I thought I
would point it out.

-- 
Bill McQuillan <[email-masked]>

Date: Tue, 17 Jul 2007 12:56:25 -0700
To: IETF SMTP <[email-masked]>
From: SM <[email-masked]>
Subject: Re: acceptings partically a message (3)
Sender: [email-masked]

Hi Dilyan,
At 10:22 17-07-2007, Dilyan Palauzov wrote:
>Let's limit us now on hosts, that do not offer PRDR.
>
>** 550 Mail for [email-masked] rejected **
>
> > The 550 code means that mail to the above-mentioned recipients 
> ([email-masked] and
> > [email-masked] was rejected for policy reasons. A DSN 
> may be sent by server.example.com
> > to both recipients. The recipients may not see your reject 
> message or they may not understand it.
>
>Is there any software nowadays, that sends DSN to the recipients 
>telling them that they cannot receive emails?

Some MTAs still send DSNs to the recipients to inform them that their 
email could not be delivered.  For example, if this email is not 
accepted by the mail server that operates this mailing list, I will 
get a DSN from my mail server.

Quoting Section 6.1 of RFC 2821:

    "When the receiver-SMTP accepts a piece of mail (by sending a "250 OK"
    message in response to DATA), it is accepting responsibility for
    delivering or relaying the message.  It must take this responsibility
    seriously."

>In my eyes, for normal users when a server answers with "550 Mail 
>rejected", the sending user receives a mail, telling her "The server 
>said: 550 Mail for [email-masked] rejected". What does the 
>user think now? Does she come to the idea, despite what is written 
>in RFC 2821, that the mail has reached no of the other recipients or 
>she is unable to understand this non-standard message, while having 
>no problems with interpreting standard responses?

The normal user may see the mail (DSN) as incomprehensible.  There is 
no guarantee that the reject message will be relayed to the sending 
user.  People actually expect email to work (mail delivered to 
intended recipient).  The expectations wans as they gain first hand 
experience of the side-effects of antispam measures.

>The problem is with mailing list software, which will be unable to 
>automatically unsubscribe faulty addresses. LSoft has solved it in 
>listserv using 'passive probing" (see the second half titled 
>"passive probes" in 
>http://www.lsoft.com/news/techtipLSV-issue1-2006-us.asp ). The 
>mailing lists are therefore not such a big problem. Imagine all 
>mails for [email-masked] are redirected to [email-masked] . 
>Already now when [email-masked] is subscribed to one mailing 
>list, and the mailbox [email-masked] disappears traceless, the mail 
>server gets the message, that mails for [email-masked] cannot be 
>delivered. But [email-masked] is not subscribed to the list. So now 
>what? (more detailed at 
>http://mail.aegee.org/lists/listowners-life.html#suspicious-subscribers 
>). It is the same as receiving "550 Mail for 
>[email-masked] rejected".

You can use VERP and track down which subscription is bouncing with it.

>Is it possible to include in 2821bis, that software implementing it 
>has to support the PRDR extension? This will be additional 
>motivation for all programmers to implement it.

That falls outside the scope of RFC 2821bis.

>2821bis compliant sounds much better than PRDR compliant and I 
>suppose the programmers shall want to be 2821bis compliant.

PRDR may have better traction that other extensions from sites 
running mail filters as they benefit from it.

>Let me rephrase my previous question:
>
>Does anybody see any _negative_concequences_ (was disadvantages) of 
>ending the session
>EHLO server.example.com
>250 OK server.example.org
>MAIL FROM:<[email-masked]>
>250 OK
>RCPT TO:<[email-masked]>
>250 OK
>RCPT TO:<[email-masked]>
>250 OK
>DATA
>354 OK
>That is all.
>.
>with
>550 Mail rejected by [email-masked]
>which _de_facto_ implies, that the mail was accepted by all but 
>[email-masked]?

Yes, I see several:

1. That reply code applies to all recipients of the message.

2. I don't understand English

3. My MTA does not convey the actual reject message to me.

4. My MTA silently drops DSNs.

Regards,
-sm 

Cc: IETF SMTP <[email-masked]>
Date: Tue, 17 Jul 2007 11:36:20 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: acceptings partically a message (3)
To: Dilyan Palauzov <[email-masked]>
Sender: [email-masked]

> Hello,

> Let's limit us now on hosts, that do not offer PRDR.

> ** 550 Mail for [email-masked] rejected **

>  > The 550 code means that mail to the above-mentioned recipients
> ([email-masked] and
>  > [email-masked] was rejected for policy reasons. A DSN may
> be sent by server.example.com
>  > to both recipients. The recipients may not see your reject message or
> they may not understand it.

> Is there any software nowadays, that sends DSN to the recipients telling
> them that they cannot receive emails?

There's tons of it. In fact there are plenty of cases where submissions
intentionally accept messages they know are undeliverable just so they can send
back a DSN later. (We routinely have customers set things up this way.) The
usual reason for this is to work around incompetent clients that fail to
display error messages correctly or consistently. (Such clients are, sad to
say, fairly common in some places.)

> In my eyes, for normal users when a server answers with "550 Mail
> rejected", the sending user receives a mail, telling her "The server
> said: 550 Mail for [email-masked] rejected".

It depends on when the error is detected. If the error is detected during
initial submission the user agent typically throws up a window containing
whatever message the server put out. (But not always - see above.) Whether or
not there's additional information in that window is hugely client dependent -
it can vary from just an unadorned message to an elaborate display with the
actual server error appearing only as a kind of footnote, or in some cases
isn't displayed at all.

If, OTOH, the error is detected during a relay operation, which is the norm
with the sorts of errors you have been talking about, the SMTP client takes the
error it got from the server and constructs a DSN to send to the user. The DSN
will say something along the lines of "sending mail to these addresses failed,
the server gave this reason for the failure". And how the DSN is actually 
displayed is also client dependent.

> What does the user think now?

With your proposal the user is likely to be very confused because odds
are they got a message in effect saying:

    Could not send mail to a,b,c because "b was rejected".

A short time later there's a nonnegligable chance said user will be on hold
waiting for customer support from their ISP. This is not a direction that will
bring joy to the hearts of the folks who run large mail systems.

> Does she come to the idea, despite what is written in
> RFC 2821, that the mail has reached no of the other recipients or she is
> unable to understand this non-standard message, while having no problems
> with interpreting standard responses?

You're missing the fact that the actual server error is often only a small part
of the error report the user sees. The SMTP server that produced the error has
no control whatsoever over how this stuff is displayed and you're making all
sorts of assumptions about how things are displayed that simply are not true in
practice.

You're also depending on the ability of the user to actually read the error
message and understand it. What happens if the user does not understand the
language the error message is written in? One of the goals of the DSN design is
to allow for localization of error messages, either by generating the DSN in
the language appropriate for the user or perhaps by having the client discard
the first part of a standard DSN and replace it with text generated from the
second machine readable part. But that implies that the semantics of the error
have to be provided by the error code and the context in which the error
appeared - you cannot count on the text part of the message communicating
anything whatsoever.

> The problem is with mailing list software, which will be unable to
> automatically unsubscribe faulty addresses.

That's another problem, but it is far from the only, or even the most major,
flaw in your proposal.

> LSoft has solved it in
> listserv using 'passive probing" (see the second half titled "passive
> probes" in http://www.lsoft.com/news/techtipLSV-issue1-2006-us.asp ).
> The mailing lists are therefore not such a big problem.

Wrong again, I'm afraid. This might be the case if what you were generating is
false negatives, that is, effectively saying that such and such an error is
valid when it is not. Periodic probing (which has been around for several
decades at least) is a reasonable way to get rid of addresses you cannot
otherwise figure out are bad.

But probes aren't much of a defense against false positives. A significant
number of list managers that receive an authoritative indication that an entire
group of  addresses they just tried to send to are bad are going to unsubscribe
them all right away rather than wait for a later probe to confirm that the
addresses are bogus. And this even ignores the very real possibility that
server responses can be influenced by the number of recipients. And you cannot
count on the fact that this was a response to a message body rather than to an
individual recipient being a factor in the list manager's decision. In fact in
many cases this distinction will not be visible to the list manager, which may
be extracting this information from a DSN.

> Imagine all
> mails for [email-masked] are redirected to [email-masked] .
> Already now when [email-masked] is subscribed to one mailing
> list, and the mailbox [email-masked] disappears traceless, the mail
> server gets the message, that mails for [email-masked] cannot be
> delivered. But [email-masked] is not subscribed to the list. So now
> what? (more detailed at
> http://mail.aegee.org/lists/listowners-life.html#suspicious-subscribers
> ). It is the same as receiving "550 Mail for [email-masked]
> rejected".

I fail to see how any of this is relevant to the matter at hand.

> Is it possible to include in 2821bis, that software implementing it has
> to support the PRDR extension?

Absolutely not. That would be a major addition of functionality and as such a
violation of process rules for 2821bis advancement. Heck, PRDR is just an
individual draft at this point, and even worse it appears to be one without a
significant amount of community support. (I personally think PRDR is a very
good idea but my personal opinion of it doesn't change my assessment that the
community has showed limited interest.) It would have to be at least published
proposed standard before we could even consider adopting it as part of  a
future revision of 2821bis.

> This will be additional motivation for
> all programmers to implement it. 2821bis compliant sounds much better
> than PRDR compliant and I suppose the programmers shall want to be
> 2821bis compliant.

> Let me rephrase my previous question:

> Does anybody see any _negative_concequences_ (was disadvantages) of
> ending the session
> EHLO server.example.com
> 250 OK server.example.org
> MAIL FROM:<[email-masked]>
> 250 OK
> RCPT TO:<[email-masked]>
> 250 OK
> RCPT TO:<[email-masked]>
> 250 OK
> DATA
> 354 OK
> That is all.
> .
> with
> 550 Mail rejected by [email-masked]
> which _de_facto_ implies, that the mail was accepted by all but
> [email-masked]?

It does not imply that. See above for why and why IMO this proposal is a total
nonstarter.

If you want to proceed constructively I suggest you talk with Eric about
getting PRDR moving again. I for one will happily support that, although the
most optimistic course I can see forward for it would result in it only having
some impact several years from now.

				Ned

Date: Tue, 17 Jul 2007 13:55:36 -0400
From: "David F. Skoll" <[email-masked]>
To: [email-masked]
Subject: Re: acceptings partically a message (3)
Sender: [email-masked]

Dilyan Palauzov wrote:

> Does anybody see any _negative_concequences_ (was disadvantages) of
> ending the session
>...
> .
> with
> 550 Mail rejected by [email-masked]
> which _de_facto_ implies, that the mail was accepted by all but
> [email-masked]?

Yes.  It's completely against the RFC.  The text part after 550 is ignored
by the SMTP client state machine.  If it receives 550 after ".", then it
MUST assume that NONE of the original recipients received the mail.

The SMTP client is encouraged to preserve any text after the 550 when
it composes a DSN, but it's not obliged to.  So any extra information
passed in the human-readable text may be lost.

--
David.

X-Mail-Sent-By-AEGEE.org-Account: Dilyan [email-masked]
Date: Tue, 17 Jul 2007 19:22:18 +0200
From: Dilyan Palauzov <[email-masked]>
To: IETF SMTP <[email-masked]>
Subject: acceptings partically a message (3)
Sender: [email-masked]

Hello,

Let's limit us now on hosts, that do not offer PRDR.

** 550 Mail for [email-masked] rejected **

 > The 550 code means that mail to the above-mentioned recipients 
([email-masked] and
 > [email-masked] was rejected for policy reasons. A DSN may 
be sent by server.example.com
 > to both recipients. The recipients may not see your reject message or 
they may not understand it.

Is there any software nowadays, that sends DSN to the recipients telling 
them that they cannot receive emails?

In my eyes, for normal users when a server answers with "550 Mail 
rejected", the sending user receives a mail, telling her "The server 
said: 550 Mail for [email-masked] rejected". What does the 
user think now? Does she come to the idea, despite what is written in 
RFC 2821, that the mail has reached no of the other recipients or she is 
unable to understand this non-standard message, while having no problems 
with interpreting standard responses?

The problem is with mailing list software, which will be unable to 
automatically unsubscribe faulty addresses. LSoft has solved it in 
listserv using 'passive probing" (see the second half titled "passive 
probes" in http://www.lsoft.com/news/techtipLSV-issue1-2006-us.asp ). 
The mailing lists are therefore not such a big problem. Imagine all 
mails for [email-masked] are redirected to [email-masked] . 
Already now when [email-masked] is subscribed to one mailing 
list, and the mailbox [email-masked] disappears traceless, the mail 
server gets the message, that mails for [email-masked] cannot be 
delivered. But [email-masked] is not subscribed to the list. So now 
what? (more detailed at 
http://mail.aegee.org/lists/listowners-life.html#suspicious-subscribers 
). It is the same as receiving "550 Mail for [email-masked] 
rejected".

 >> How many envelopes I receive do have more than one recipient? Well,
 >> except the spam almost nothing. But imagine a mailing list that
 >> has 1000 subscribers. 10 mails for sure will go for the same domain,
 >> so for that 10 subscribers giving a temporary error after the
 >> second RCPT would lead to huge delays (<=> grey listing).

 > If you are greylisting, in my opinion, it needs to be for the ENTIRE
 > transaction, not just individuals. I doubt it will work right and again
 > your end can do what it wants, but you won't be able to change the
 > SENDER behavior who is designed to work with a standard expected
 > behavior. If you send a 45x at the DATA, then the entire transaction
 > MAY be tried again. A 55x will not be tried again - period.

Giving temporary reject to a user is the same as applying greylisting 
for that user. I do not want to apply greylisting at all, however when 
one suggests to accept all but the first recipient and reject temporary 
the others, he means that applying (a kind of) greylisting is the way to 
make per recipient responses. Up to now it was just not labelled 
grey-listing.

Is it possible to include in 2821bis, that software implementing it has 
to support the PRDR extension? This will be additional motivation for 
all programmers to implement it. 2821bis compliant sounds much better 
than PRDR compliant and I suppose the programmers shall want to be 
2821bis compliant.

Let me rephrase my previous question:

Does anybody see any _negative_concequences_ (was disadvantages) of 
ending the session
EHLO server.example.com
250 OK server.example.org
MAIL FROM:<[email-masked]>
250 OK
RCPT TO:<[email-masked]>
250 OK
RCPT TO:<[email-masked]>
250 OK
DATA
354 OK
That is all.
.
with
550 Mail rejected by [email-masked]
which _de_facto_ implies, that the mail was accepted by all but 
[email-masked]?

Със здраве,
Дилян

Date: Tue, 17 Jul 2007 12:35:43 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked], Dilyan Palauzov <[email-masked]>
Subject: Re: acceptings partically a message (2)
Sender: [email-masked]

Arnt Gulbrandsen wrote:
> 
> Dilyan Palauzov writes:
>>   Does anybody see any disadvantages of ending the session
>>   ...
>> with
>>   550 Mail rejected by [email-masked]
>> which implies, that the mail was accepted by all but 
>> [email-masked]?
> 
> The problem I see is that 550 does not imply "accepted" at all. 550 is 
> not a partial success code.

If its not already clearly stated in 2821 and in 2821bis, then maybe 
there should be a statement added to 2821bis stating to the effect that 
a 550 not only means a permanent rejection for the transaction, but it 
also *implies* to the SENDER that the recipients ARE NOT going to 
receive the mail - atleast not "officially."

I really hope we don't open the DOOR to the idea that a SMTP server can 
begin to tell the SENDER mail was rejected but actually LIE about this 
delivery status and delivered the mail anyway.

I can understand and see how GREYLISTING implementations can help "mold" 
the thinking in this directon.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Cc: [email-masked]
Date: Tue, 17 Jul 2007 07:35:55 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: acceptings partically a message (2)
To: Dilyan Palauzov <[email-masked]>
Sender: [email-masked]

>    Hello,

>    The Arnt's approach leads to evaluating DSN as spam, thus leaving
> them unread, a.k.a. useless.

>    Does anybody see any disadvantages of ending the session

>      EHLO server.example.com
>      250 OK server.example.org
>      MAIL FROM:<[email-masked]>
>      250 OK
>      RCPT TO:<[email-masked]>
>      250 OK
>      RCPT TO:<[email-masked]>
>      250 OK
>      DATA
>      354 OK
>      That is all.
>      .

> with
>    550 Mail rejected by [email-masked]
> which implies, that the mail was accepted by all but [email-masked]?

Aside from the fact that such usage is entirely nonstandard and no SMTP client
is going to be able to deal with it, there's no disadvantage at all... In fact
SMTP clients are required to operate entirely on the basis of the reply code so
this is going to come across as all recipients having been rejected. I believe
A any other behavior from a client would actually be a standards violaation,
not to mention a bad idea.

>    How many evelopes I receive do have more than one recipient? Well,
> except the spam almost nothing. But imagine a mailing list that has
> 1000 subcribers. 10 mails for sure will go for the same domain, so for
> that 10 subscribers giving a temporary error after the second RCPT
> would lead to huge delays (<=> grey listing).

This is a very worrisome statement given that the only real way to address this
issue in general is with an extension to SMTP that provides functionality
similar to the multiple responses LMTP allows (but without the additional
semantics implied by LMTP).

The problem with SMTP extensions of this sort is that they are fairly useless
until there are enough implementations out there that there's  a good chance
the extension will be available when it is needed. If the majority of people
who are sending you messages with multiple recipients are spammers, what would
the incentive be for these spammers to implement this? I very much doubt that
spammers care about your problems returning DSNs. So if your claims are correct
where's the benefit in doing this?

This extension also has the unfortunate charactistic that clients get very
little benefit out of implementing it no matter what, and unless you already
have LMTP support in your client coding this can be a fairly nontrivial
undertaking. The server side is another matter - server side is where the
benefit is - but a bunch of servers supporting it without corresponding client
support isn't useful.

More generally, the issue with SMTP extensions is always whether the cost of
deploying it worth the benefit you get out of it. Sometimes you get lucky and
extension support deploys not because of the utility of the extension but
rather because the support happened to be in versions of popular email software
that needed to installed for other reasons. But you cannot count on this, and
deployment costs in SMTP can be surprisingly high, especially for extensions
that change the command-response structure of the protocol - think of what this
means for stateful inspection proxies, for example.

Finally, I also note that there has been at least one proposal put forward to
address this:

    http://www.watersprings.org/pub/id/draft-hall-prdr-00.txt

So at least there's a proposal on the table.

				Ned

Date: Tue, 17 Jul 2007 08:37:59 -0700
To: [email-masked]
From: SM <[email-masked]>
Subject: Re: acceptings partically a message (2)
Sender: [email-masked]

Hi Dilyan,
At 07:15 17-07-2007, Dilyan Palauzov wrote:
>   Does anybody see any disadvantages of ending the session
>
>     EHLO server.example.com
>     250 OK server.example.org
>     MAIL FROM:<[email-masked]>
>     250 OK
>     RCPT TO:<[email-masked]>
>     250 OK
>     RCPT TO:<[email-masked]>
>     250 OK
>     DATA
>     354 OK
>     That is all.
>     .
>
>with
>   550 Mail rejected by [email-masked]
>which implies, that the mail was accepted by all but [email-masked]?

The 550 code means that mail to the above-mentioned recipients 
([email-masked] and [email-masked] was rejected for 
policy reasons.  A DSN may be sent by server.example.com to both 
recipients.  The recipients may not see your reject message or they 
may not understand it.

Regards,
-sm 

Date: Tue, 17 Jul 2007 11:34:21 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Dilyan Palauzov <[email-masked]>
CC: [email-masked]
Subject: Re: acceptings partically a message (2)
Sender: [email-masked]

Dilyan Palauzov wrote:
 >
 >   Does anybody see any disadvantages of ending the session
 >
 >     EHLO server.example.com
 >     250 OK server.example.org
 >     MAIL FROM:<[email-masked]>
 >     250 OK
 >     RCPT TO:<[email-masked]>
 >     250 OK
 >     RCPT TO:<[email-masked]>
 >     250 OK
 >     DATA
 >     354 OK
 >     That is all.
 >     .
 >
 > with
 >   550 Mail rejected by [email-masked]
 > which implies, that the mail was accepted by all but
 > [email-masked]?

Sure, it changes all kinds of ideas about delivery success, status, etc.

Keep in mind that SMTP servers do not read the "Literal" part, just the 
response codes to have any real meaning.  The literal is just for 
LOGGING. It has NO (expected) AUTOMATION concept behind it

550 means the Transaction was permanently rejected and as far as the 
SMTP server is concern, none of the recipients are going to be receiving 
the mail.

Whatever you really do on your own end, thats your business, but its not 
a standard expectation and we can't be working on this basis.  A 550 at 
DATA means none of the RCPT users are expectd to be receiving the mail 
and as far as the SENDER is concern it was a FAILED DELIVERY attempt.

If you want to REJECT a recipient but continue with others, then you 
should be using a 45x for the RCPT:

     EHLO server.example.com
     250 OK server.example.org
     MAIL FROM:<[email-masked]>
     250 OK
     RCPT TO:<[email-masked]>
     250 OK
     RCPT TO:<[email-masked]>
     45x or 55x Sorry User doesn't exit
     RCPT TO:<[email-masked]>
     250 OK
     DATA
     354 OK
     [email block]
     .

Do not assume the client is going to stop at the first 45x or 55x 
response. He MAY continue with the next RCPT.   If a 55x was used, the 
specs simply says not to try again with the same information. If the 
clients want to stop, thats up it want it trying to send. If the RCPT 
list is exhausted, it might stop.  But if it got atleast 1 250 for RCPT, 
it may continue to DATA.

 > How many evelopes I receive do have more than one recipient? Well,
 > except the spam almost nothing. But imagine a mailing list that
 > has 1000 subcribers. 10 mails for sure will go for the same domain,
 > so for that 10 subscribers giving a temporary error after the
 > second RCPT would lead to huge delays (<=> grey listing).

If you are greylisting, in my opinion, it needs to be for the ENTIRE 
transaction, not just individuals.  I doubt it will work right and again 
your end can do what it wants, but you won't be able to change the 
SENDER behavior who is designed to work with a standard expected 
behavior.  If you send a 45x at the DATA, then the entire transaction 
MAY be tried again.  A 55x will not be tried again - period.

However, if you do it at the RCPT, you **MIGHT** get a sender to filter 
its RCPT in future transactions.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Tue, 17 Jul 2007 17:33:10 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: acceptings partically a message (2)
Cc: Dilyan Palauzov <[email-masked]>
Sender: [email-masked]

Dilyan Palauzov writes:
>   Does anybody see any disadvantages of ending the session
>   ...
> with
>   550 Mail rejected by [email-masked]
> which implies, that the mail was accepted by all but 
> [email-masked]?

The problem I see is that 550 does not imply "accepted" at all. 550 is 
not a partial success code.

>   How many evelopes I receive do have more than one recipient? Well,  
>   except the spam almost nothing. But imagine a mailing list that has 
>    1000 subcribers.

Many/most biggish lists use a per-recipient footer, VERP, or both. I 
suspect that's the reason why you get almost no multi-recipient 
envelopes.

Arnt

Date: Tue, 17 Jul 2007 16:15:52 +0200
From: Dilyan Palauzov <[email-masked]>
To: [email-masked]
Subject: acceptings partically a message (2)
Sender: [email-masked]

   Hello,

   The Arnt's approach leads to evaluating DSN as spam, thus leaving  
them unread, a.k.a. useless.

   Does anybody see any disadvantages of ending the session

     EHLO server.example.com
     250 OK server.example.org
     MAIL FROM:<[email-masked]>
     250 OK
     RCPT TO:<[email-masked]>
     250 OK
     RCPT TO:<[email-masked]>
     250 OK
     DATA
     354 OK
     That is all.
     .

with
   550 Mail rejected by [email-masked]
which implies, that the mail was accepted by all but [email-masked]?

   How many evelopes I receive do have more than one recipient? Well,  
except the spam almost nothing. But imagine a mailing list that has  
1000 subcribers. 10 mails for sure will go for the same domain, so for  
that 10 subscribers giving a temporary error after the second RCPT  
would lead to huge delays (<=> grey listing).

   Със здраве,
     Дилян

Date: Tue, 17 Jul 2007 15:21:19 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: acceptings partically a message
Cc: Dilyan Palauzov <[email-masked]>
Sender: [email-masked]

Ethically minded subscribers: Please stop reading now.

I just had a coffee break. On the balcony, where the sun bakes and it's 
really hot. The heat and the coffeine affected my brain, and I had a 
really evil idea.

Dilyan Palauzov writes:
> Referring to my initial email and the followed comments I would like 
> to express the reason of why exactly this behaviour is needed to 
> reject spam. Well, the only other option is to send DSN. However the 
> DNS may end in a spamtrap/honeypot, thus blacklisting your MTA, just 
> because it sent DSN.

Do you have an ISP or perhaps even several? Ideally residential DSL 
connection(s) from a big ISP?

You could set up a tunnel so that when your MTA attempts a connection to 
e.g. 192.0.4.4 port 25, the connection finally arrives at the smarthost 
of an ISP and appears to originate from (one of) your residential DSL 
connection(s). If you have a VPN linking people's homes to the company 
network this shouldn't be too hard.

Then you configure your MTA to deliver DSNs via 192.0.4.4 and all other 
mail directly, and tralala, if there's a problem Spamcop will blacklist 
that big ISP instead of your MTA.

Nasty, isn't it? Evil? Terrible? You think I should be spanked, and you 
hope the postmaster of my own ISP reads this list? (He does.)

Arnt

Date: Tue, 17 Jul 2007 13:36:51 +0100
From: "Peter Bowyer" <[email-masked]>
To: [email-masked]
Subject: Re: acceptings partically a message
Sender: [email-masked]

On 17/07/07, Arnt Gulbrandsen <[email-masked]> wrote:
>
> Separate reply.
>
> Dilyan Palauzov writes:
> > Moreover doing temporary rejects for all but one recipient means
> > practically applying grey-listing, with all it delays and is not an
> > option at all.
>
> "practically"? Do you mean that MANY of your incoming messages have more
> than one recipient (before alias expansion)?

And being slightly smarter, of those that have more than one
recipient, how many of them actually need different reject handling?
ie you can accept more than one recipient if you know they're all
going to be handled identically post-DATA. You only need to defer
those that are not.

Peter

-- 
Peter Bowyer
Email: [email-masked]

Date: Tue, 17 Jul 2007 14:29:46 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: acceptings partically a message
Cc: Dilyan Palauzov <[email-masked]>
Sender: [email-masked]

Separate reply.

Dilyan Palauzov writes:
> Moreover doing temporary rejects for all but one recipient means 
> practically applying grey-listing, with all it delays and is not an 
> option at all.

"practically"? Do you mean that MANY of your incoming messages have more 
than one recipient (before alias expansion)?

Arnt

Date: Tue, 17 Jul 2007 14:26:55 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: acceptings partically a message
Cc: Dilyan Palauzov <[email-masked]>
Sender: [email-masked]

Dilyan Palauzov writes:
> Are there any better ideas?

You can also set the maximum number of recipients on your SMTP server(s) 
to 1. Then you'll have a different set of disadvantages.

Arnt

X-Mail-Sent-By-AEGEE.org-Account: Dilyan [email-masked]
Date: Tue, 17 Jul 2007 13:35:31 +0200
From: Dilyan Palauzov <[email-masked]>
To: IETF SMTP <[email-masked]>
Subject: Re: acceptings partically a message
Sender: [email-masked]

  Hello,

Referring to my initial email and the followed comments I would like to 
express the reason of why exactly this behaviour is needed to reject 
spam. Well, the only other option is to send DSN. However the DNS may 
end in a spamtrap/honeypot, thus blacklisting your MTA, just because it 
sent DSN. This is a real disaster I had to experience, as spamcop 
blacklists servers, who bounce spam messages.

So the schema

 > if all rejected
>  answer "CR LF . CR LF" with 5xx
>  else if all accepted
>  2xx
>  else
>  2xx, and send a DSN with the exact details

is not at all an option. Moreover doing temporary rejects for all but 
one recipient means practically applying grey-listing, with all it 
delays and is not an option at all. At the same time I do not expect 
that the spammer's SMTP servers will ever implement PRDR, so my vote 
goes for

S: 550 Mail rejected for [email-masked]

except the server supports PRDR. Are there any better ideas?

Със здраве,
Дилян

Date: Tue, 17 Jul 2007 11:55:58 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: acceptings partically a message
Cc: John C Klensin <[email-masked]>, Claus Assmann <[email-masked]>
Sender: [email-masked]

John C Klensin writes:
> --On Tuesday, 17 July, 2007 11:30 +0200 Arnt Gulbrandsen
> <[email-masked]> wrote:
>
>>  John C Klensin writes:
>>>  Is there something I'm missing?
>>
>>  RFC3028 and friends. It's practical for each of spamtrap and 
>>  mailing-list to reject or accept based on the contents of the 
>>  message.
>
> But that didn't seem to be the question, at least as I read it.

Indeed. It responds only to the question of whether you're missing something.

> And the comment about the low likelihood of the putative spammer 
> asking for a proposed extension still stands.

Absolutely.

Arnt

Date: Tue, 17 Jul 2007 05:41:51 -0400
From: John C Klensin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>, [email-masked]
cc: Claus Assmann <[email-masked]>
Subject: Re: acceptings partically a message
Sender: [email-masked]

--On Tuesday, 17 July, 2007 11:30 +0200 Arnt Gulbrandsen
<[email-masked]> wrote:

> John C Klensin writes:
>> Is there something I'm missing?
> 
> RFC3028 and friends. It's practical for each of spamtrap and
> mailing-list to reject or accept based on the contents of the
> message.

But that didn't seem to be the question, at least as I read it.
And the comment about the low likelihood of the putative spammer
asking for a proposed extension still stands.

> My code to implement this does
> 
>      if all rejected
>         answer "CR LF . CR LF" with 5xx
>     else if all accepted
>         2xx
>     else
>         2xx, and send a DSN with the exact details
> 
> The third case is very, very uncommon in practice, so I'm not
> all that worried by its ill effects.

yep.  It is also no worse than "accept everything, send DSNs as
needed later" which, for better or worse, 2821 explicitly
contemplates.

    john

Date: Tue, 17 Jul 2007 11:30:37 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: acceptings partically a message
Cc: John C Klensin <[email-masked]>, Claus Assmann <[email-masked]>
Sender: [email-masked]

John C Klensin writes:
> Is there something I'm missing?

RFC3028 and friends. It's practical for each of spamtrap and 
mailing-list to reject or accept based on the contents of the message.

My code to implement this does

     if all rejected
        answer "CR LF . CR LF" with 5xx
    else if all accepted
        2xx
    else
        2xx, and send a DSN with the exact details

The third case is very, very uncommon in practice, so I'm not all that 
worried by its ill effects.

Arnt

Date: Tue, 17 Jul 2007 05:19:04 -0400
From: John C Klensin <[email-masked]>
To: "Robert A. Rosenberg" <[email-masked]>
cc: [email-masked]
Subject: Re: draft-klensin-rfc2821bis-04: VRFY and EXPN syntax
Sender: [email-masked]

--On Monday, 16 July, 2007 21:25 -0400 "Robert A. Rosenberg"
<[email-masked]> wrote:

> 
> At 15:08 -0400 on 07/15/2007, John C Klensin wrote about Re:
> draft-klensin-rfc2821bis-04: VRFY and EXPN syntax:
> 
>> Partially because of the circumlocutions and security
>> consideration  issues, there is a lot of text about VRFY and
>> EXPN in 2821bis.
> 
> If I may put in my 2 cents, I'd like to hopefully see some
> comments about the security issues in using VRFY and EXPN in
> the security section (if they are not already there) as well
> as an EXPLICATE MUST that the EHLO reply ONLY list them if
> they have not been turned off (IOW: If you are going to reject
> them or send a "Send Me A massage" reply to an attempt to VRFY
> then do not advertise support for them in the first place).

Please read the spec before posting comments like this to the
list.  For this purpose, either RFC 2821 or
draft-klensin-rfc2821bis-04 will do although I'd prefer to have
comments on the latter if you are suggesting new text.  You will
find that there are comments in the Security Considerations
section already (about 3/4 page worth, enough of them to rate a
whole subsection) and there is also an explanation of why your
suggestion about the EHLO advertisements would be ill-advised.

More generally, rfc2821bis is getting fairly late-stage at this
point.  The odds that a suggestion will be accepted rise
dramatically if it actually and clearly identifies a bug and/or
if it comes with specific suggested text.  Otherwise, absent
fairly strong consensus that the issue is important, the
overworked and exhausted editor is unlikely to find the energy
to make up text, figure out where to put it, and then ask people
to review that text.

      john

Date: Tue, 17 Jul 2007 11:13:52 +0200
From: Alex van den Bogaerdt <[email-masked]>
To: IETF SMTP <[email-masked]>
Subject: Re: acceptings partically a message
Sender: [email-masked]

On Tue, Jul 17, 2007 at 05:01:27AM -0400, John C Klensin wrote:
> 
> Excuse me, but why is this complicated?
> 
> While PRDR may be very useful, it isn't needed here.  More
> important, if the message really is spam, the odds that the
> spammer will request PRDR seems to me to be slight to none...
> and it might not be desirable to give the spammers that much
> information if they did ask for it.
> 
> So you have
> 
> C:  MAIL FROM:<[email-masked]>
> S:  250 OK, I suppose
> C:  RCPT TO:<[email-masked]>
> S:  250 Ok, amuse yourself
> C:  RCPT TO:<[email-masked]>
> S:  550 As far as you are concerned, no such address
> C:  DATA
> S:  354 Go
>  [...]
> 
> Is there something I'm missing?

It is about content, not about sender address.

If the content is spam, <[email-masked]> does want it,
<[email-masked]> does not.

You can only tell after DATA is finished.

Date: Tue, 17 Jul 2007 05:01:27 -0400
From: John C Klensin <[email-masked]>
To: Claus Assmann <[email-masked]>, IETF SMTP <[email-masked]>
Subject: Re: acceptings partically a message
Sender: [email-masked]

Excuse me, but why is this complicated?

While PRDR may be very useful, it isn't needed here.  More
important, if the message really is spam, the odds that the
spammer will request PRDR seems to me to be slight to none...
and it might not be desirable to give the spammers that much
information if they did ask for it.

So you have

C:  MAIL FROM:<[email-masked]>
S:  250 OK, I suppose
C:  RCPT TO:<[email-masked]>
S:  250 Ok, amuse yourself
C:  RCPT TO:<[email-masked]>
S:  550 As far as you are concerned, no such address
C:  DATA
S:  354 Go
 [...]

Is there something I'm missing?

      john

--On Monday, 16 July, 2007 22:25 -0700 Claus Assmann
<[email-masked]> wrote:

> 
> On Tue, Jul 17, 2007, Dilyan Palauzov wrote:
> 
>> My use case is, that I want to accept a message partially
>> during the  SMTP dialog. Imagine one mail with two
>> recipients, [email-masked]  and
>> [email-masked] is coming to my server. I do not
>> want to  accept the mail for [email-masked], since
>> later it will be  bounced, may end in a spamtrap and my
>> server will be blacklisted. At the  same time I want to
>> accept the mail for (my) [email-masked], in  order to
>> improve my spam filter.
> 
> See:
> http://www.ietf.org/internet-drafts/draft-hall-prdr-00.txt
> 
>> MAIL FROM: [email-masked]
> 
> Wrong syntax:
> MAIL FROM:<[email-masked]>
> 
>> RCPT TO: [email-masked]
> 
> Same here.
> 
>> 250 OK
>> RCPT TO: [email-masked]
> 
> and again.
> 
>> 451 Try again later
> 
> That's the current way to deal with the problem if PRDR isn't
> supported.
>...

Date: Mon, 16 Jul 2007 22:25:56 -0700
From: Claus Assmann <[email-masked]>
To: IETF SMTP <[email-masked]>
Subject: Re: acceptings partically a message
Mail-Followup-To: IETF SMTP <[email-masked]>
Sender: [email-masked]

On Tue, Jul 17, 2007, Dilyan Palauzov wrote:

> My use case is, that I want to accept a message partially during the 
> SMTP dialog. Imagine one mail with two recipients, [email-masked] 
> and [email-masked] is coming to my server. I do not want to 
> accept the mail for [email-masked], since later it will be 
> bounced, may end in a spamtrap and my server will be blacklisted. At the 
> same time I want to accept the mail for (my) [email-masked], in 
> order to improve my spam filter.

See:
http://www.ietf.org/internet-drafts/draft-hall-prdr-00.txt

> MAIL FROM: [email-masked]

Wrong syntax:
MAIL FROM:<[email-masked]>

> RCPT TO: [email-masked]

Same here.

> 250 OK
> RCPT TO: [email-masked]

and again.

> 451 Try again later

That's the current way to deal with the problem if PRDR isn't
supported.

[[2nd approach: reject after final dot]]
> .
> 550 Mail rejected by [email-masked]

If you only want to train your spam filter, then you may as well
"cheat" and reject the mail at the end, but still feed it into your
filter (just makie sure not to generate a bounce).

Anyway, the right solution is PRDR. Help supporting it!

Date: Mon, 16 Jul 2007 23:17:09 -0600
From: Philip Guenther <[email-masked]>
To: "Robert A. Rosenberg" <[email-masked]>
cc: [email-masked]
Subject: Re: draft-klensin-rfc2821bis-04: VRFY and EXPN syntax
Sender: [email-masked]

On Mon, 16 Jul 2007, Robert A. Rosenberg wrote:
> At 15:08 -0400 on 07/15/2007, John C Klensin wrote about Re: 
> draft-klensin-rfc2821bis-04: VRFY and EXPN syntax:
>
>> Partially because of the circumlocutions and security consideration issues, 
>> there is a lot of text about VRFY and EXPN in 2821bis.
>
> If I may put in my 2 cents, I'd like to hopefully see some comments 
> about the security issues in using VRFY and EXPN in the security section 
> (if they are not already there) as well

Didn't believe John when he said "a lot of text", eh?  Your worries should 
have been assuaged by a glance a the table of contents of 
draft-klensin-rfc2821bis-04.txt:

    7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 76
      7.1.  Mail Security and Spoofing . . . . . . . . . . . . . . . . 76
      7.2.  "Blind" Copies . . . . . . . . . . . . . . . . . . . . . . 77
      7.3.  VRFY, EXPN, and Security . . . . . . . . . . . . . . . . . 78
...

> as an EXPLICATE MUST that the 
> EHLO reply ONLY list them if they have not been turned off (IOW: If you 
> are going to reject them or send a "Send Me A massage" reply to an 
> attempt to VRFY then do not advertise support for them in the first 
> place).

I disagree.

Can you give some reason for treating the EXPN and VRFY service extensions 
any differently than other extensions?

Can you give some justification for specifying "MUST NOT list unless 
supported" instead of SHOULD NOT?  What critical interoperability problems 
occur when that isn't followed?  Given that there are legitimate reasons 
for a VRFY or EXPN to fail even when it is supported, or perhaps to fail 
for some but not all arguments, I fail to see the benefit of attempting to 
tighten this requirement.

Philip Guenther

X-Mail-Sent-By-AEGEE.org-Account: Dilyan [email-masked]
Date: Tue, 17 Jul 2007 07:12:16 +0200
From: Dilyan Palauzov <[email-masked]>
To: IETF SMTP <[email-masked]>
Subject: acceptings partically a message
Sender: [email-masked]

  Hello,

My use case is, that I want to accept a message partially during the 
SMTP dialog. Imagine one mail with two recipients, [email-masked] 
and [email-masked] is coming to my server. I do not want to 
accept the mail for [email-masked], since later it will be 
bounced, may end in a spamtrap and my server will be blacklisted. At the 
same time I want to accept the mail for (my) [email-masked], in 
order to improve my spam filter.

How shall such messages be accepted for some recipients and rejected for 
others.
I want to use this on port 25. Even if LMTP has this nice feature, it is 
out of question.

So far I am aware of two two ideas:

EHLO server.example.com
250 OK server.example.org
MAIL FROM: [email-masked]
250 OK
RCPT TO: [email-masked]
250 OK
RCPT TO: [email-masked]
451 Try again later
DATA ...

or

EHLO server.example.com
250 OK server.example.org
MAIL FROM: [email-masked]
250 OK
RCPT TO: [email-masked]
250 OK
RCPT TO: [email-masked]
250 OK
DATA
354 OK
That is all.
.
550 Mail rejected by [email-masked]

In the first case we make grey-listing, in the second there is no 
confirmation for which addresses the mail is received.
What is the more correct way to implement this partially acceptance?

Със здраве,
Дилян

Date: Mon, 16 Jul 2007 21:25:30 -0400
To: [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: draft-klensin-rfc2821bis-04: VRFY and EXPN syntax
Sender: [email-masked]

At 15:08 -0400 on 07/15/2007, John C Klensin wrote about Re: 
draft-klensin-rfc2821bis-04: VRFY and EXPN syntax:

>Partially because of the circumlocutions and security consideration 
>issues, there is a lot of text about VRFY and EXPN in 2821bis.

If I may put in my 2 cents, I'd like to hopefully see some comments 
about the security issues in using VRFY and EXPN in the security 
section (if they are not already there) as well as an EXPLICATE MUST 
that the EHLO reply ONLY list them if they have not been turned off 
(IOW: If you are going to reject them or send a "Send Me A massage" 
reply to an attempt to VRFY then do not advertise support for them in 
the first place).

Date: Mon, 16 Jul 2007 14:10:41 -0400
From: John C Klensin <[email-masked]>
To: "Peter J. Holzer" <[email-masked]>, [email-masked]
Subject: Re: draft-klensin-rfc2821bis-04: VRFY and EXPN syntax
Sender: [email-masked]

--On Monday, July 16, 2007 9:46 AM +0200 "Peter J. Holzer" 
<[email-masked]> wrote:

>...
>|   For the VRFY command, the string is a user name or a user
>|   name and domain (see below).  If a normal (i.e., 250)
>|   response is returned, the response MAY include the full
>|   name of the user and MUST include the mailbox of the user.
>|   It MUST be in either of the following forms:
>
>
> But that snippet indicates that the notion what a "user name"
> is changed during the preparation of RFC 2821: "user name and
> domain" just doesn't make sense when the user name already
> includes the domain.

Nope.  Your follow-up suggestion may be helpful, but the spec 
anticipated (and some implementations have historically 
supported)

  VRFY john
to which the response could be any of
  * One mailbox, possibly with a display name
  * One mailbox and an indication that there were others
  * A list of mailboxes in a multiline response
  * An indication that the request was ambiguous
  * An indication that VRFY wasn't really supported, at least 
with that syntax.

One might prefer a more precisely specified command, but it is 
more than 20 years too late.

>...

    john

Date: Mon, 16 Jul 2007 10:56:13 -0700
To: [email-masked]
From: SM <[email-masked]>
Subject: Re: draft-klensin-rfc2821bis-04: VRFY and EXPN syntax
Sender: [email-masked]

Hi Peter,
At 01:15 16-07-2007, Peter J. Holzer wrote:
>Speaking of local mailboxes and user names, I think it is extremely
>inadvisable to let VRFY return a list of real addresses on a partial
>match. If "VRFY john" returns a list of all addresses of users whose
>first or last name is John, it is simple to harvest addresses.

That would only be a problem if VRFY is not restricted.  Section 
3.5.2 states that VRFY is not required to work across 
relays.  Section 3.5 is about commands for debugging 
addresses.  There is already a warning about disabling these commands 
for security reasons.

"In many cases, RCPT commands can be used to obtain the same 
information about address validity."

Regards,
-sm 

Date: Mon, 16 Jul 2007 10:04:28 -0700
To: [email-masked]
From: SM <[email-masked]>
Subject: Re: draft-klensin-rfc2821bis-04: VRFY and EXPN syntax
Sender: [email-masked]

Hi Peter,
At 00:46 16-07-2007, Peter J. Holzer wrote:
> >   For the VRFY command, the string is a user name or a user name and
> >   domain and it MUST be in either of the following forms:
>
>You cut too much here. The "it" refers to the response, not the string:

You are right.  That wasn't my intent.

   For the VRFY command, the string is a user name or a user name and
   domain and the response MUST be in either of the following forms:

>|   For the VRFY command, the string is a user name or a user name and
>|   domain (see below).  If a normal (i.e., 250) response is returned,
>|   the response MAY include the full name of the user and MUST include
>|   the mailbox of the user.  It MUST be in either of the following
>|   forms:
>
>
>But that snippet indicates that the notion what a "user name" is changed
>during the preparation of RFC 2821: "user name and domain" just doesn't
>make sense when the user name already includes the domain.

Yes.  It would be better if the text was more straight-forward.  But 
it may be too big a change as you mentioned in a previous email.

>Also the description of the string argument is split into 3 paragraphs
>with different material between, which makes it a bit hard to follow.
>Maybe the whole section should be rearranged:
>
>
>    SMTP provides commands to verify a address or obtain the content of
>    a mailing list.  This is done with the VRFY and EXPN commands, which
>    have character string arguments.  Implementations SHOULD support VRFY
>    and EXPN (however, see Section 3.5.2 and Section 7.3).
>
>    The string argument is used to identify a user, a mailbox or a
>    mailing-list.  An implementation of the VRFY or EXPN commands MUST at
>    least recognize the exact names of local mailboxes in the standard
>    "local-part@domain" format (see Section 2.3.11).  Hosts MAY also
>    choose to recognize other strings, for example the mailbox address
>    enclosed in angle brackets, the local part of an address or a
>    substring of the full name of the user owning the mailbox.

That changes the meaning somewhat as the string now identifies one 
user or one mailbox.  Quoting draft-04:

    "When a name that is the argument to VRFY could identify more than one
    mailbox, the server MAY either note the ambiguity or identify the
    alternatives."

Although your text is clearer, it changes the above.  Stepping back, 
VRFY is there to verify a "user name" and is useful for 
debugging.  The response may identify the alternative mailboxes if 
there is no exact match.

>    The character string arguments of the VRFY and EXPN commands cannot
>    be further restricted due to the variety of implementations of the
>    user name and mailbox list concepts.  On some systems it may be
>    appropriate for the argument of the EXPN command to be a file name
>    for a file containing a mailing list, but again there are a variety
>    of file naming conventions in the Internet.  Similarly, historical
>    variations in what is returned by these commands are such that the
>    response SHOULD be interpreted very carefully, if at all, and SHOULD
>    generally only be used for diagnostic purposes.
>
>and then the rest of the section with minor changes.
>
>I've eliminated the term "user name", because strictly speaking that
>relates only to VRFY, not to EXPN. I have also probably changed the
>intended meaning a bit: I think "local mailbox" was intended to refer
>only to the local part of the address (otherwise "local-part@domain
>SHOULD be recognized" makes no sense) but that contradicts section
>2.3.11, which states that a mailbox is identified by an address of the
>form local-part@domain. So to be consistent I've made that form
>compulsory and listed "local part only" as one of the optional other
>forms.

No, local mailboxes does not refer to the local part of the address 
only.  A host may handle mail for more than one domain.  We may have 
local-part@domain returning more than one possibility.  All this may 
sound ambiguous when compared with the other sections of the RFC.

In this example:

        C: VRFY <[email-masked]>
        S: 250 smith <[email-masked]>

the mailbox is [email-masked].

>Hmm. I'd prefer it if the RFC clearly specified one specific format
>which must be recognized. If some implementations require the user name
>to be enclosed in angle brackets and some require it not to be enclosed
>in angle brackets the client needs to try both. See above for an
>alternate clarification which makes the address without angle brackets
>mandatory and with angle brackets optional, which is closer to my
>understanding of the current RFC.

I'd prefer that too.  But it may not be possible if it affects 
existing implementations.  However, if people agree to the change, 
please use "pointed" brackets instead of angle brackets.

Regards,
-sm 

Date: Mon, 16 Jul 2007 17:32:33 +0100
To: Douglas Otis <[email-masked]>, John C Klensin <[email-masked]>
From: Paul Smith <[email-masked]>
Subject: Re: draft-klensin-rfc2821bis-04: VRFY and EXPN syntax
Cc: [email-masked]
Sender: [email-masked]

At 15:12 16/07/2007, Douglas Otis wrote:

>On Jul 15, 2007, at 12:08 PM, John C Klensin wrote:
>
>>That said, I could see doing something else if there was general
>>consensus that it would be worthwhile.  Partially because of the
>>circumlocutions and security consideration issues, there is a lot
>>of text about VRFY and EXPN in 2821bis.  I may regret saying this
>>but, without looking at the spec, I think I could separate that
>>material out into a separate document called "SMTP VRFY and EXPN
>>Commands" or words to that effect.  This would not change the basic
>>specification or requirements at all, but would shorten the SMTP
>>spec itself, keeping text that that did not have any VRFY/EXPN
>>details.
>
>When operating as a backup or preprocessing MTA as a service for
>third-parties, normally verifying valid recipients is handled by
>using some form of LDAP or Active Directory.  This lowers the number
>of bounces that might be otherwise generated.  A VRFY enabled on an
>MTA that only accepts this command or messages from a backup or
>preprocessing MTA can function as an alternative to LDAP when this
>information is cached.
>
>Microsoft, for Exchange 2000 or 2003, dropped full support for this
>command and always returns 252 2.1.5 Cannot VRFY user, as VRFY is
>always advertised.  The proper response can not be enabled via a
>registry setting, even when the MTA only responds to a trusted
>upstream MTA.  Specific event driven software must be added before
>this function can operate as intended, which of course makes LDAP/ 
>Active Directory a simpler choice. : (

Using LDAP only works reliably if the mail server and LDAP server are 
tightly coupled. This is quite unusual outside of the Microsoft 
Exchange world. Also, the LDAP server needs to know about aliases and 
mailing lists, again, this is by no means a given.

LDAP is a directory protocol, it is not specifically tied to email at 
all. You can have an LDAP server without an SMTP server, and vice versa.

VRFY would seem to me to be the 'proper' way to do this, or a trial 
'RCPT TO' command. Using LDAP seems to be a kludge. If I have an SMTP 
server, then there is no guarantee at all that there is an LDAP 
server associated with it, and, if there is, no guarantee that it is 
up to date, or has complete information. On the other hand, if the 
SMTP server supports VRFY itself, then it is pretty certain it's 
going to be up to date.

I'd prefer VRFY to be continued, and potentially have notes 
discussing the problems with a poorly implemented version. If the 
alternative is for every SMTP server to have to have a 
tightly-coupled LDAP server, then that's a step in the wrong direction IMHO.

Just because Microsoft Exchange doesn't support it very well, doesn't 
mean that VRFY should be scrapped - just that people should use 
better mail servers...

Cc: [email-masked]
From: Douglas Otis <[email-masked]>
Subject: Re: draft-klensin-rfc2821bis-04: VRFY and EXPN syntax
Date: Mon, 16 Jul 2007 07:12:09 -0700
To: John C Klensin <[email-masked]>
Sender: [email-masked]

On Jul 15, 2007, at 12:08 PM, John C Klensin wrote:

> That said, I could see doing something else if there was general  
> consensus that it would be worthwhile.  Partially because of the  
> circumlocutions and security consideration issues, there is a lot  
> of text about VRFY and EXPN in 2821bis.  I may regret saying this  
> but, without looking at the spec, I think I could separate that  
> material out into a separate document called "SMTP VRFY and EXPN  
> Commands" or words to that effect.  This would not change the basic  
> specification or requirements at all, but would shorten the SMTP  
> spec itself, keeping text that that did not have any VRFY/EXPN  
> details.

When operating as a backup or preprocessing MTA as a service for  
third-parties, normally verifying valid recipients is handled by  
using some form of LDAP or Active Directory.  This lowers the number  
of bounces that might be otherwise generated.  A VRFY enabled on an  
MTA that only accepts this command or messages from a backup or  
preprocessing MTA can function as an alternative to LDAP when this  
information is cached.

Microsoft, for Exchange 2000 or 2003, dropped full support for this  
command and always returns 252 2.1.5 Cannot VRFY user, as VRFY is  
always advertised.  The proper response can not be enabled via a  
registry setting, even when the MTA only responds to a trusted  
upstream MTA.  Specific event driven software must be added before  
this function can operate as intended, which of course makes LDAP/ 
Active Directory a simpler choice. : (

-Doug

Date: Mon, 16 Jul 2007 09:37:34 +0100
To: Markus Stumpf <[email-masked]>, Kari Hurtta <[email-masked]>
From: Paul Smith <[email-masked]>
Subject: Re: draft-klensin-rfc2821bis-04: VRFY and EXPN syntax
Cc: [email-masked], John C Klensin <[email-masked]>
Sender: [email-masked]

At 22:29 14/07/2007, Markus Stumpf wrote:

>On Sat, Jun 16, 2007 at 10:05:20AM +0300, Kari Hurtta wrote:
> > 4.1.1.6.  VERIFY (VRFY)
> > 4.1.1.7.  EXPAND (EXPN)
>
>Does anybody know about any MTA actively using these today?
>Is there any secenario (besides address harvesting) within which these
>are still useful in todays email communication?

I have seen VRFY used by spam filter appliances/services for checking 
whether an email address is valid, and also whether an alias which 
resolves to a different mailbox.

This can be useful for licencing requirements, eg a '10 user' spam 
filter might get a message for sales@.. and fred@... If it can tell 
that sales@ resolves to fred@ by using VRFY, it can treat it as '1 
user', if it relies on a test RCPT TO, then it has to treat it as 2 users.

Some spam filters use LDAP for this, but this relies on either the 
LDAP server being tied to the mail server somehow (which is by no 
means certain unless you are working in a MS Exchange/Lotus Domino 
world) or the sysadmin keeping them both in sync (again which is by 
no means certain). Using VRFY means that you are only asking the mail 
server about mail addresses, which it should know, rather than asking 
a totally separate server about them.

For address harvesting, using dummy RCPT TOs can be just as useful, 
because you don't care if an address is an alias, but for legitimate 
management purposes like this it does matter.

I haven't seen anyone use EXPN, but it's not hard to implement.

>IMHO most MTAs support the commands but respond something like:
>     252 send some mail, i'll try my best

Our MTA has a set of restrictions so you can tell it which IP 
addresses it will support VRFY and EXPN for, so for most people it 
will return an error, but for the IP address of a spam filter service 
it will work properly. So, if YOU were to test our mail server you'd 
think they weren't supported, but they are (for a select few).

>Why not simply drop them completely?

I'd say no. Possibly make them an extension, or an option, but they 
do play a purpose that can't be achieved any other way, and they're 
pretty trivial to implement.

Date: Mon, 16 Jul 2007 10:15:25 +0200
From: "Peter J. Holzer" <[email-masked]>
To: [email-masked]
Subject: Re: draft-klensin-rfc2821bis-04: VRFY and EXPN syntax
Mail-Followup-To: [email-masked]
Sender: [email-masked]

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

[I normally try to avoid following up to myself on a mailing-list,=20
 but I think this matter is independent of a reformulation of section
 3.5.1, so this is in a separate message]

On 2007-07-16 09:46:48 +0200, Peter J. Holzer wrote:
>    The string argument is used to identify a user, a mailbox or a
>    mailing-list.  An implementation of the VRFY or EXPN commands MUST at
>    least recognize the exact names of local mailboxes in the standard
>    "local-part@domain" format (see Section 2.3.11).  Hosts MAY also
>    choose to recognize other strings, for example the mailbox address
>    enclosed in angle brackets, the local part of an address or a
>    substring of the full name of the user owning the mailbox.

Speaking of local mailboxes and user names, I think it is extremely
inadvisable to let VRFY return a list of real addresses on a partial
match. If "VRFY john" returns a list of all addresses of users whose
first or last name is John, it is simple to harvest addresses.

So, section 7.3 should warn about this possibility, maybe by adding the
following paragraph after the last:

    The specification of the VRFY command allows (but does not require)
    that all addresses matching the string argument are returned in a
    553 response. This may be used to harvest addresses by searching for
    common names (see examples in section 3.5.1). If an implementation
    supports recognition of anything except exact mailbox addresses,
    it SHOULD provide for a way to disable this feature. I.e., there
    SHOULD be a mode in which VRFY can only be used to determine if an
    exact address does or does not exist, but not to retrieve additional
    addresses.

	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"

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

--/WwmFnJnmDyWGHa4--

Date: Mon, 16 Jul 2007 09:46:48 +0200
From: "Peter J. Holzer" <[email-masked]>
To: [email-masked]
Subject: Re: draft-klensin-rfc2821bis-04: VRFY and EXPN syntax
Mail-Followup-To: [email-masked]
Sender: [email-masked]

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

On 2007-07-15 12:11:48 -0700, SM wrote:
>=20
> At 10:17 15-07-2007, Peter J. Holzer wrote:
> >>
> >>        C: VRFY <[email-masked]>
> >>        S: 250 smith <[email-masked]>
> >>
> >>     or
> >>
> >>        C: VRFY [email-masked]
> >>        S: 250 smith <[email-masked]>
> >
> >The last two would be a separate example, I think.
>=20
> It could go after the second paragraph of Section 3.5.1.
>=20
>=20
>   For the VRFY command, the string is a user name or a user name and
>   domain and it MUST be in either of the following forms:

You cut too much here. The "it" refers to the response, not the string:

|   For the VRFY command, the string is a user name or a user name and
|   domain (see below).  If a normal (i.e., 250) response is returned,
|   the response MAY include the full name of the user and MUST include
|   the mailbox of the user.  It MUST be in either of the following
|   forms:

But that snippet indicates that the notion what a "user name" is changed
during the preparation of RFC 2821: "user name and domain" just doesn't
make sense when the user name already includes the domain.

Also the description of the string argument is split into 3 paragraphs
with different material between, which makes it a bit hard to follow.
Maybe the whole section should be rearranged:

   SMTP provides commands to verify a address or obtain the content of
   a mailing list.  This is done with the VRFY and EXPN commands, which
   have character string arguments.  Implementations SHOULD support VRFY
   and EXPN (however, see Section 3.5.2 and Section 7.3).

   The string argument is used to identify a user, a mailbox or a
   mailing-list.  An implementation of the VRFY or EXPN commands MUST at
   least recognize the exact names of local mailboxes in the standard
   "local-part@domain" format (see Section 2.3.11).  Hosts MAY also
   choose to recognize other strings, for example the mailbox address
   enclosed in angle brackets, the local part of an address or a
   substring of the full name of the user owning the mailbox.

   The character string arguments of the VRFY and EXPN commands cannot
   be further restricted due to the variety of implementations of the
   user name and mailbox list concepts.  On some systems it may be
   appropriate for the argument of the EXPN command to be a file name
   for a file containing a mailing list, but again there are a variety
   of file naming conventions in the Internet.  Similarly, historical
   variations in what is returned by these commands are such that the
   response SHOULD be interpreted very carefully, if at all, and SHOULD
   generally only be used for diagnostic purposes.

and then the rest of the section with minor changes.

I've eliminated the term "user name", because strictly speaking that
relates only to VRFY, not to EXPN. I have also probably changed the
intended meaning a bit: I think "local mailbox" was intended to refer
only to the local part of the address (otherwise "local-part@domain
SHOULD be recognized" makes no sense) but that contradicts section
2.3.11, which states that a mailbox is identified by an address of the
form local-part@domain. So to be consistent I've made that form
compulsory and listed "local part only" as one of the optional other
forms.

> >|  An implementation of the VRFY or EXPN commands MUST include at least
> >|  recognition of local mailboxes as "user names".  However, since
> >|  current Internet practice often results in a single host handling
> >|  mail for multiple domains, hosts, especially hosts that provide this
> >|  functionality, SHOULD accept the "local-part@domain" form as a "user
> >|  name";
> >
> >So "local maiboxes" MUST be supported ans "local-part@domain" SHOULD be
> >supported. But how is a mailbox specified?
> >
> >|  The standard mailbox naming convention is defined to be
> >|  "local-part@domain":
> >
> >Seems a bit redundant to prescribe the same form both via MUST and
> >SHOULD.
>=20
> How about:
>=20
>    "User name" is a fuzzy term and has been used deliberately.  An
>    implementation of the VRFY or EXPN commands MUST include at least
>    recognition of local mailboxes as "user names".  However, since
>    current Internet practice often results in a single host handling
>    mail for multiple domains, hosts, especially hosts that provide this
>    functionality, MUST accept the "local-part@domain" form as a "user
>    name"; hosts MAY also choose to recognize other strings as "user
>    names" or require the user name to be enclosed in pointed brackets.
> Regards,
> -sm=20

Hmm. I'd prefer it if the RFC clearly specified one specific format
which must be recognized. If some implementations require the user name
to be enclosed in angle brackets and some require it not to be enclosed
in angle brackets the client needs to try both. See above for an
alternate clarification which makes the address without angle brackets
mandatory and with angle brackets optional, which is closer to my
understanding of the current RFC.

	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"

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

--J2SCkAp4GZ/dPZZf--

Date: Sun, 15 Jul 2007 23:32:47 +0400
From: Alexey Melnikov <[email-masked]>
To: SM <[email-masked]>
CC: Markus Stumpf <[email-masked]>, [email-masked]
Subject: Re: draft-klensin-rfc2821bis-04: VRFY and EXPN syntax
Sender: [email-masked]

SM wrote:
> At 14:29 14-07-2007, Markus Stumpf wrote:
>> On Sat, Jun 16, 2007 at 10:05:20AM +0300, Kari Hurtta wrote:
>> > 4.1.1.6.  VERIFY (VRFY)
>> > 4.1.1.7.  EXPAND (EXPN)
>>
>> Does anybody know about any MTA actively using these today?
>> Is there any secenario (besides address harvesting) within which these
>> are still useful in todays email communication?
> VRFY is still useful for address verification.  It is disabled in the 
> default configuration of some MTAs due to abuse.
In our MTA VRFY/EXPN are disabled by default. They can be enabled 
unconditionally or require SMTP AUTH.
>> IMHO most MTAs support the commands but respond something like:
>>     252 send some mail, i'll try my best
>>
>> Why not simply drop them completely?
 [...]
> Note that the draft-04 mentions that "Server implementations" should 
> support both VRFY and EXPN and leaves it to local installations to 
> disable them if need be.  By dropping them, we are removing 
> functionality that is useful for debugging.
Agreed.

Date: Sun, 15 Jul 2007 12:11:48 -0700
To: [email-masked]
From: SM <[email-masked]>
Subject: Re: draft-klensin-rfc2821bis-04: VRFY and EXPN syntax
Cc: John C Klensin <[email-masked]>
Sender: [email-masked]

At 10:17 15-07-2007, Peter J. Holzer wrote:
> >
> >        C: VRFY <[email-masked]>
> >        S: 250 smith <[email-masked]>
> >
> >     or
> >
> >        C: VRFY [email-masked]
> >        S: 250 smith <[email-masked]>
>
>The last two would be a separate example, I think.

It could go after the second paragraph of Section 3.5.1.

   For the VRFY command, the string is a user name or a user name and
   domain and it MUST be in either of the following forms:

       User Name <local-part@domain>
       local-part@domain

   If a normal (i.e., 250) response is returned, the response MAY 
include the full name
   of the user and MUST include the mailbox of the user.  The 
following cases show a
   normal response:

         C: VRFY <[email-masked]>
         S: 250 smith <[email-masked]>

      or

         C: VRFY [email-masked]
         S: 250 smith <[email-masked]>

   When a user name that is the argument to VRFY could identify more 
than one ...

> > The before last example is for a user name and domain.  Although it
> > is accepted by some implementations, and I believe, readily used, it
> > does not fit the description for a string as a user name.
>
>It falls under 'hosts MAY also choose to recognize other strings as
>"user names"'. The last form is IMHO the only form which must be
>supported:

I'm not so sure about that.  I suggested some text below to clarify that.

>|  An implementation of the VRFY or EXPN commands MUST include at least
>|  recognition of local mailboxes as "user names".  However, since
>|  current Internet practice often results in a single host handling
>|  mail for multiple domains, hosts, especially hosts that provide this
>|  functionality, SHOULD accept the "local-part@domain" form as a "user
>|  name";
>
>So "local maiboxes" MUST be supported ans "local-part@domain" SHOULD be
>supported. But how is a mailbox specified?
>
>|  The standard mailbox naming convention is defined to be
>|  "local-part@domain":
>
>Seems a bit redundant to prescribe the same form both via MUST and
>SHOULD.

How about:

    "User name" is a fuzzy term and has been used deliberately.  An
    implementation of the VRFY or EXPN commands MUST include at least
    recognition of local mailboxes as "user names".  However, since
    current Internet practice often results in a single host handling
    mail for multiple domains, hosts, especially hosts that provide this
    functionality, MUST accept the "local-part@domain" form as a "user
    name"; hosts MAY also choose to recognize other strings as "user
    names" or require the user name to be enclosed in pointed brackets.
Regards,
-sm 

Date: Sun, 15 Jul 2007 15:08:05 -0400
From: John C Klensin <[email-masked]>
To: "Peter J. Holzer" <[email-masked]>, [email-masked]
Subject: Re: draft-klensin-rfc2821bis-04: VRFY and EXPN syntax
Sender: [email-masked]

--On Sunday, July 15, 2007 7:25 PM +0200 "Peter J. Holzer" 
<[email-masked]> wrote:

> On 2007-07-14 22:25:43 -0700, SM wrote:
>> Note that the draft-04 mentions that "Server implementations"
>> should  support both VRFY and EXPN and leaves it to local
>> installations to  disable them if need be.  By dropping them,
>> we are removing  functionality that is useful for debugging.
>
> They could be moved to an extension. EXPN is already optional
> and while VRFY must be supported it can be (and is frequently)
> turned off - so in practice you can't rely on it. The only
> difference to other extensions is that they are specified in
> the core SMTP spec instead of in a separate RFC.
>
> Moving them to a separate RFC would reflect current practice.
> However, this may be too large a change for the transition
> from proposed to draft standard.

In my opinion, they cannot be moved to an extension for the 
procedural reason that RFC 1123 requires their support.  The 
dancing around about servers being required to support them but 
installations taking them out --and how that was supposed to be 
done/reflected down to specific reply codes-- was a DRUMS 
decision reflecting that 1123 requirement.  Despite some other 
tuning, 2821bis has not changed that part of the specification 
in any substantive way.

That is probably just another way of saying what Peter suggests 
above: this is too big a change for proposed-> draft just 
because, although the rules in 2026 and its successors are much 
better designed for new specifications rather than updating old 
(full)standards, the baseline here is presumably the 821/ 1123 
requirements, not the clean slate of a new proposed standard.

That said, I could see doing something else if there was general 
consensus that it would be worthwhile.  Partially because of the 
circumlocutions and security consideration issues, there is a 
lot of text about VRFY and EXPN in 2821bis.  I may regret saying 
this but, without looking at the spec, I think I could separate 
that material out into a separate document called "SMTP VRFY and 
EXPN Commands" or words to that effect.  This would not change 
the basic specification or requirements at all, but would 
shorten the SMTP spec itself, keeping text that that did not 
have any VRFY/EXPN details.

The arguments against doing that are that any major textual 
change risks getting things wrong and it would require that the 
now-long-overdue ABNF revision project break the ABNF up for two 
separate documents.

Again, just my personal views.

     john

Date: Sun, 15 Jul 2007 19:25:55 +0200
From: "Peter J. Holzer" <[email-masked]>
To: [email-masked]
Subject: Re: draft-klensin-rfc2821bis-04: VRFY and EXPN syntax
Mail-Followup-To: [email-masked]
Sender: [email-masked]

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

On 2007-07-14 22:25:43 -0700, SM wrote:
> Note that the draft-04 mentions that "Server implementations" should=20
> support both VRFY and EXPN and leaves it to local installations to=20
> disable them if need be.  By dropping them, we are removing=20
> functionality that is useful for debugging.

They could be moved to an extension. EXPN is already optional and while
VRFY must be supported it can be (and is frequently) turned off - so in
practice you can't rely on it. The only difference to other extensions
is that they are specified in the core SMTP spec instead of in a
separate RFC.=20

Moving them to a separate RFC would reflect current practice. However,
this may be too large a change for the transition from proposed to draft
standard.

	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"

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

--E/DnYTRukya0zdZ1--

Date: Sun, 15 Jul 2007 19:17:48 +0200
From: "Peter J. Holzer" <[email-masked]>
To: [email-masked]
Subject: Re: draft-klensin-rfc2821bis-04: VRFY and EXPN syntax
Mail-Followup-To: [email-masked]
Sender: [email-masked]

--s/l3CgOIzMHHjg/5
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2007-07-14 23:50:25 -0700, SM wrote:
>=20
> At 17:09 14-07-2007, Peter J. Holzer wrote:
> >Yes. When I did some experiments with SMTP callbacks some time ago, I
> >found that most MTAs return that (I wonder what advertising the VRFY
> >capability in the EHLO response and then returning a useless result is
> >supposed to accomplish ...), but even worse, some expected the email
> >address in angle brackets and some without, so you would get false
> >negatives unless you tried both ... Too much trouble for too little
> >gain.
>=20
> It might be better to list VRFY in the EHLO response only if the=20
> command is supported by the installation.  The "if EXPN is supported,=20
> it MUST be listed as a service extension in an EHLO response." would=20
> still apply.
>=20
> Draft-04 does not specify that angle brackets must be used.

Right.

> The example in that section could be clearer if it was:
>=20
>       C: VRFY smith
>       S: 553 User ambiguous
>=20
>    or
>=20
>       C: VRFY smith
>       S: 553- Ambiguous; Possibilities are
>       S: 553-Joe Smith <[email-masked]>
>       S: 553-Harry Smith <[email-masked]>
>       C: 553 Melvin Smith <[email-masked]>
>=20
>    or
>=20
>       C: VRFY smith
>       S: 553-Ambiguous; Possibilities
>       S: 553- <[email-masked]>
>       S: 553- <[email-masked]>
>       S: 553 <[email-masked]>
>=20
>     or
>=20
>        C: VRFY <[email-masked]>
>        S: 250 smith <[email-masked]>
>=20
>     or
>=20
>        C: VRFY [email-masked]
>        S: 250 smith <[email-masked]>

The last two would be a separate example, I think.=20

> The before last example is for a user name and domain.  Although it=20
> is accepted by some implementations, and I believe, readily used, it=20
> does not fit the description for a string as a user name.

It falls under 'hosts MAY also choose to recognize other strings as
"user names"'. The last form is IMHO the only form which must be
supported:

|  An implementation of the VRFY or EXPN commands MUST include at least
|  recognition of local mailboxes as "user names".  However, since
|  current Internet practice often results in a single host handling
|  mail for multiple domains, hosts, especially hosts that provide this
|  functionality, SHOULD accept the "local-part@domain" form as a "user
|  name";

So "local maiboxes" MUST be supported ans "local-part@domain" SHOULD be
supported. But how is a mailbox specified?=20

|  The standard mailbox naming convention is defined to be
|  "local-part@domain":

Seems a bit redundant to prescribe the same form both via MUST and
SHOULD.

	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"

--s/l3CgOIzMHHjg/5
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

--s/l3CgOIzMHHjg/5--

Date: Sat, 14 Jul 2007 23:50:25 -0700
To: "Peter J. Holzer" <[email-masked]>, [email-masked]
From: SM <[email-masked]>
Subject: Re: draft-klensin-rfc2821bis-04: VRFY and EXPN syntax
Cc: John C Klensin <[email-masked]>
Sender: [email-masked]

At 17:09 14-07-2007, Peter J. Holzer wrote:
>Yes. When I did some experiments with SMTP callbacks some time ago, I
>found that most MTAs return that (I wonder what advertising the VRFY
>capability in the EHLO response and then returning a useless result is
>supposed to accomplish ...), but even worse, some expected the email
>address in angle brackets and some without, so you would get false
>negatives unless you tried both ... Too much trouble for too little
>gain.

It might be better to list VRFY in the EHLO response only if the 
command is supported by the installation.  The "if EXPN is supported, 
it MUST be listed as a service extension in an EHLO response." would 
still apply.

Draft-04 does not specify that angle brackets must be used.  The 
example in that section could be clearer if it was:

       C: VRFY smith
       S: 553 User ambiguous

    or

       C: VRFY smith
       S: 553- Ambiguous; Possibilities are
       S: 553-Joe Smith <[email-masked]>
       S: 553-Harry Smith <[email-masked]>
       C: 553 Melvin Smith <[email-masked]>

    or

       C: VRFY smith
       S: 553-Ambiguous; Possibilities
       S: 553- <[email-masked]>
       S: 553- <[email-masked]>
       S: 553 <[email-masked]>

     or

        C: VRFY <[email-masked]>
        S: 250 smith <[email-masked]>

     or

        C: VRFY [email-masked]
        S: 250 smith <[email-masked]>

The before last example is for a user name and domain.  Although it 
is accepted by some implementations, and I believe, readily used, it 
does not fit the description for a string as a user name.

Regards,
-sm 

Date: Sat, 14 Jul 2007 22:25:43 -0700
To: Markus Stumpf <[email-masked]>
From: SM <[email-masked]>
Subject: Re: draft-klensin-rfc2821bis-04: VRFY and EXPN syntax
Cc: [email-masked]
Sender: [email-masked]

At 14:29 14-07-2007, Markus Stumpf wrote:

>On Sat, Jun 16, 2007 at 10:05:20AM +0300, Kari Hurtta wrote:
> > 4.1.1.6.  VERIFY (VRFY)
> > 4.1.1.7.  EXPAND (EXPN)
>
>Does anybody know about any MTA actively using these today?
>Is there any secenario (besides address harvesting) within which these
>are still useful in todays email communication?

VRFY is still useful for address verification.  It is disabled in the 
default configuration of some MTAs due to abuse.

>IMHO most MTAs support the commands but respond something like:
>     252 send some mail, i'll try my best
>
>Why not simply drop them completely?

We have resorted to using hacks to get around VRFY restrictions, i.e. 
using RCPT TO: for address verification.  VRFY can be used for 
address verification in some scenarios, e.g. backup MX against MX 
doing delivery.

I rarely use EXPN.  It can be useful for debugging.

Note that the draft-04 mentions that "Server implementations" should 
support both VRFY and EXPN and leaves it to local installations to 
disable them if need be.  By dropping them, we are removing 
functionality that is useful for debugging.

Regards,
-sm 

Date: Sun, 15 Jul 2007 02:09:37 +0200
From: "Peter J. Holzer" <[email-masked]>
To: [email-masked]
Subject: Re: draft-klensin-rfc2821bis-04: VRFY and EXPN syntax
Mail-Followup-To: [email-masked]
Sender: [email-masked]

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

On 2007-07-14 23:29:31 +0200, Markus Stumpf wrote:
> On Sat, Jun 16, 2007 at 10:05:20AM +0300, Kari Hurtta wrote:
> > 4.1.1.6.  VERIFY (VRFY)
> > 4.1.1.7.  EXPAND (EXPN)
>=20
> Does anybody know about any MTA actively using these today?
> Is there any secenario (besides address harvesting) within which these
> are still useful in todays email communication?

I don't think so. VRFY might be useful for SMTP address verification
(indeed there are people who maintain that using VRFY for that purpose
is ok but using MAIL FROM:<>/RCPT TO:<address> is abuse), but it's too
little supported and too unreliable for that.

As for EXPN, I don't think there is a valid use on unauthenticated SMTP
connections.

> IMHO most MTAs support the commands but respond something like:
>     252 send some mail, i'll try my best

Yes. When I did some experiments with SMTP callbacks some time ago, I
found that most MTAs return that (I wonder what advertising the VRFY
capability in the EHLO response and then returning a useless result is
supposed to accomplish ...), but even worse, some expected the email
address in angle brackets and some without, so you would get false
negatives unless you tried both ... Too much trouble for too little
gain.

> Why not simply drop them completely?

Might as well.

	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"

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

--61jdw2sOBCFtR2d/--

Date: Sat, 14 Jul 2007 23:29:31 +0200
From: Markus Stumpf <[email-masked]>
To: Kari Hurtta <[email-masked]>
Cc: [email-masked], John C Klensin <[email-masked]>
Subject: Re: draft-klensin-rfc2821bis-04: VRFY and EXPN syntax
Organization: LEO - Link Everything Online, Munich, Germany
Sender: [email-masked]

On Sat, Jun 16, 2007 at 10:05:20AM +0300, Kari Hurtta wrote:
> 4.1.1.6.  VERIFY (VRFY)
> 4.1.1.7.  EXPAND (EXPN)

Does anybody know about any MTA actively using these today?
Is there any secenario (besides address harvesting) within which these
are still useful in todays email communication?

IMHO most MTAs support the commands but respond something like:
    252 send some mail, i'll try my best

Why not simply drop them completely?
(And yes, I'd reread Ned's comments from March 2007 to this list).

	\Maex

Date: Mon, 09 Jul 2007 02:21:28 -0400
From: Tony Hansen <[email-masked]>
To: [email-masked]
Subject: [Fwd: I-D Action:draft-hansen-4468upd-mailesc-registry-02.txt]
Sender: [email-masked]

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

--------------020705020107080706090103
Content-Type: message/rfc822;
 name="I-D Action:draft-hansen-4468upd-mailesc-registry-02.txt.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename*0="I-D Action:draft-hansen-4468upd-mailesc-registry-02.txt.eml"

To: [email-masked]
Cc: 
From: [email-masked]
Date: Mon, 09 Jul 2007 02:20:01 -0400
Subject: I-D Action:draft-hansen-4468upd-mailesc-registry-02.txt 
Reply-To: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
                                                                                           
        Title           : A Registry for SMTP Enhanced Mail System Status Codes
        Author(s)       : T. Hansen
        Filename        : draft-hansen-4468upd-mailesc-registry-02.txt
        Pages           : 12
        Date            : 2007-07-08
                                                                                           
This document establishes an IANA registry for SMTP Enhanced Status
Codes.
                                                                                           
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hansen-4468upd-mailesc-registry-02.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-hansen-4468upd-mailesc-registry-02.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-hansen-4468upd-mailesc-registry-02.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-hansen-4468upd-mailesc-registry-02.txt
                                                                                           
--OtherAccess
Content-Type: Message/External-body;
	name="draft-hansen-4468upd-mailesc-registry-02.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"
Content-Type: text/plain
Content-ID: <2007-07-09021112.I-D\@ietf.org>

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

--------------020705020107080706090103--

Date: Thu, 05 Jul 2007 14:37:48 -0700
To: [email-masked], [email-masked]
From: SM <[email-masked]>
Subject: Re: mailing list RFCs?
Sender: [email-masked]

Hi Andrew,
At 17:05 04-07-2007, Andrew Van Tassel wrote:
>I also see a problem when the From: is not not changed and other 
>headers are removed.  Often lists add or remove fields to the 
>message header as stated above.

Most mailing lists modify the Subject header.  They don't change the 
 From header.  They may also modify the Reply-To header.

>I guess I'm trying to find the standard of processing mailing lists 
>within a legitimate organization.  So far, imc.org seems to uphold a 
>good policy.  Then again if any of my headers are missing when I 
>receive this it could be an issue.....

At the end of the day, the mailing list administrators determine 
their policy.  Whatever the RFCs says won't change that.

Regards,
-sm 

Date: Wed, 04 Jul 2007 20:05:52 -0400
From: Andrew Van Tassel <[email-masked]>
Reply-To: [email-masked]
Organization: Message Level, LLC.
To: [email-masked]
Subject: mailing list RFCs?
Sender: [email-masked]

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

Has anyone looked at any of the following RFCs? My only concern is the 
amount of spoofing that occurs
with the current mailing lists process. Some may say this is a 
"legitimate spoof".

This one expires July 2007.

http://www.ietf.org/internet-drafts/draft-ietf-eai-mailinglist-01.txt

To Quote:

    Some mailing lists alter the message header, while others do not. A
number of standardized list-related header fields have been defined,
and many lists add these headers. Separate from these standardized
list-specific header fields, and despite a history of
interoperability problems from doing so, some lists alter or add
header fields in an attempt to control where replies are sent. Such
lists typically add or replace the "Reply-To" field and some add or
replace the "Sender" field. Poorly-behaved lists may alter or
replace other fields, including "From".

I also see a problem when the From: is not not changed and other headers 
are removed.  Often lists add or remove fields to the message header as 
stated above.

This maybe the first RFC that talks about lists.

http://www.ietf.org/rfc/rfc2369.txt

To Quote:

    Mail list processors should not allow any user-originated list header
fields to pass through to their lists, lest they confuse the user and
have the potential to create security problems.

Now it doesn't define "user-originated" but if this means headers added 
by the original sending MUA or MTA I see issues with this.

Another describing List-ID

http://www.ietf.org/rfc/rfc2919.txt

I guess I'm trying to find the standard of processing mailing lists 
within a legitimate organization.  So far, imc.org seems to uphold a 
good policy.  Then again if any of my headers are missing when I receive 
this it could be an issue.....

happy 4th!

-Andrew

--------------000902050306090504000603
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
<small><font face="Courier New"><small><big>Has anyone looked at any of
the following RFCs? My only concern is the amount of spoofing that
occurs <br>
with the current mailing lists process. Some may say this is a
"legitimate spoof".<br>
<br>
This one expires July 2007.<br>
</big></small><br>
<small><big><a class="moz-txt-link-freetext" href="http://www.ietf.org/internet-drafts/draft-ietf-eai-mailinglist-01.txt">http://www.ietf.org/internet-drafts/draft-ietf-eai-mailinglist-01.txt</a></big></small><br>
<br>
<small><big>To Quote:</big></small><br>
<br>
<small><big>&nbsp;&nbsp;&nbsp; Some mailing lists alter the message header, while
others do not. A<br>
number of standardized list-related header fields have been defined,<br>
and many lists add these headers. Separate from these standardized<br>
list-specific header fields, and despite a history of<br>
interoperability problems from doing so, some lists alter or add<br>
header fields in an attempt to control where replies are sent. Such<br>
lists typically add or replace the "Reply-To" field and some add or<br>
replace the "Sender" field. Poorly-behaved lists may alter or<br>
replace other fields, including "From".<br>
<br>
I also see a problem when the From: is not not changed and other
headers are removed.&nbsp; Often lists add or remove fields to the message
header as stated above.<br>
<br>
This maybe the first RFC that talks about lists.<br>
<br>
<a class="moz-txt-link-freetext" href="http://www.ietf.org/rfc/rfc2369.txt">http://www.ietf.org/rfc/rfc2369.txt</a><br>
</big></small><br>
<small><big>To Quote:</big></small><br>
<br>
<small><big>&nbsp;&nbsp;&nbsp; Mail list processors should not allow any
user-originated list header<br>
fields to pass through to their lists, lest they confuse the user and<br>
have the potential to create security problems.<br>
</big></small><br>
<small><big>Now it doesn't define "user-originated" but if this means
headers added by the original sending MUA or MTA I see issues with this.</big></small><br>
<br>
<small><big>Another describing List-ID</big></small><br>
<br>
<small><big><a class="moz-txt-link-freetext" href="http://www.ietf.org/rfc/rfc2919.txt">http://www.ietf.org/rfc/rfc2919.txt</a></big></small></font></small><br>
<br>
I guess I'm trying to find the standard of processing mailing lists
within a legitimate organization.&nbsp; So far, imc.org seems to uphold a
good policy.&nbsp; Then again if any of my headers are missing when I
receive this it could be an issue.....<br>
<br>
happy 4th!<br>
<br>
-Andrew<br>
<br>
</body>
</html>

--------------000902050306090504000603--