headers
Randall Gellens | 1 Jun 2007 01:13

Re: rfc2821bis-04, Issue 38: MX queuing behavior with options


I think it would be good to have some discussion.  The harder 
question is what to say.  I'd like to say that there are some 
extensions where lack of support is an especially bad thing, and 
where there are some hints to the client-side that the recipient 
server normally supports them.  The example I'm thinking of is 
UTF8SMTP, since lack of support when the message requires it means 
the message must be bounced or possibly worse, downgraded.  The 
downgrade can split the recipients into separate trees, where some 
recipients don't see the others, and hence a 'reply all' misses them 
entirely.  In addition, with UTF8SMTP, there is some assumption that 
a UTF8 address implies that the recipient's server supports the 
extension, otherwise where did the address come from?  For these 
extensions, it might be a better choice to try another server rather 
than do violence to the message.
--

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Pohl's law:
    Nothing is so good that somebody, somewhere, will not hate it.
Permalink | Reply | 0 comments |
headers
SM | 1 Jun 2007 02:01

Re: rfc2821bis-04, Issue 38: MX queuing behavior with options


Hi John,
At 13:39 31-05-2007, John C Klensin wrote:
>While I have no recollection that we ever thought of or
>discussed it, the situation changed when we adopted the
>extension mechanism.  Suddenly, we could have two servers at the
>same preference level, one of which supported a given extension
>and one which did not.   There is a case to be made that this
>would be a dumb way to configure things, but I don't think we
>say that anywhere, much less make equivalent configurations a
>requirement.   The situation is similar, but arguably worse, for
>systems with less-desirable preference levels: again, there is
>no requirement that they support all of the extension
>capabilities of the destination server.

It may happen that two servers at the same preference level may not 
support the same extensions.  I'll assume that it's not the general 
case and that if it happens, remedial action can be taken as the two 
servers would most likely be under the same administrative control.

>Suppose we have a client that would really prefer to send mail
>to user <at> foo.example using the FOOBAR extension.  An MX query on
>foo.example yields
>     foo.example. IN MX 10 smtp1.foo.example.
>                  IN MX 10 smtp2.foo.example.
>                  IN MX 20 backup.foo.example.
>
>Suppose it tries smtp2.foo.example, gets the SMTP connection
>open, but the EHLO response does not contain FOOBAR.  Is it
>required to proceed using the non-FOOBAR behavior, or may it
(Continue reading)

Permalink | Reply | 0 comments |
headers
SM | 1 Jun 2007 05:57

Re: rfc2821bis-04, Issue 38: MX queuing behavior with options


At 16:13 31-05-2007, Randall Gellens wrote:
>recipients don't see the others, and hence a 'reply all' misses them 
>entirely.  In addition, with UTF8SMTP, there is some assumption that 
>a UTF8 address implies that the recipient's server supports the 
>extension, otherwise where did the address come from?

That assumption can cause problems if the address is generated by a 
rogue process.

Regards,
-sm
Permalink | Reply | 0 comments |
headers
Tony Finch | 1 Jun 2007 12:43
Picon
Favicon

Re: rfc2821bis-04, Issue 38: MX queuing behavior with options


On Thu, 31 May 2007, John C Klensin wrote:
>
> I believe that, with the way the text in 2821 is written, a
> client that is successful in opening an SMTP session (getting
> the 220 greeting, sending an EHLO command, and getting a
> response) to at least one of smtp1 or smtp2 is not permitted to
> fall back to backup.foo.example under any circumstances.

No: it says "the SMTP client MUST be able to try each of the relevant
addresses in this list in order, until a delivery attempt succeeds", so
after a successfully established connection but a failed (4yz) delivery
the client will try another server.

Tony.
--

-- 
f.a.n.finch  <dot <at> dotat.at>  http://dotat.at/
DOGGER: EAST OR NORTHEAST 3 OR 4. SLIGHT OR MODERATE. SHOWERS, FOG PATCHES.
MODERATE OR GOOD, OCCASIONALLY VERY POOR.
Permalink | Reply | 1 comment |
headers
ned+ietf-smtp | 1 Jun 2007 15:16

Re: rfc2821bis-04, Issue 38: MX queuing behavior with options


> On Thu, 31 May 2007, John C Klensin wrote:
> >
> > I believe that, with the way the text in 2821 is written, a
> > client that is successful in opening an SMTP session (getting
> > the 220 greeting, sending an EHLO command, and getting a
> > response) to at least one of smtp1 or smtp2 is not permitted to
> > fall back to backup.foo.example under any circumstances.

> No: it says "the SMTP client MUST be able to try each of the relevant
> addresses in this list in order, until a delivery attempt succeeds", so
> after a successfully established connection but a failed (4yz) delivery
> the client will try another server.

Not necessarily, if for no other reason than that some believe there's
a difference between a successful *delivery* and a successful delivery
*attempt*.

As a practical matter the further in to the transaction the faiure occurs the
more time and resources the client has devoted to this one delivery (no doubt
out of many pending) and the less likely that other MXes will succeed where
this one has failed. The question is where to draw the line: Some
implementations do as you say and will retry all MXes in the event of a 4yz
error at any  point, others may give up on receipt of a 4xy as banner greeting
and still others put the cut point somewhere between the beginning and the end.
And there are also some clients that take the type of 4yz error into account.
But since clients don't have a crystal ball to consult this becomes a question
of what are the best heuristics to use.

My personal position is that it definitely makes sense to retry if the failure
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Crocker | 6 Jun 2007 17:01

[Fwd: Last Call: draft-hutzler-spamops (Email Submission: Access and Accountability) to BCP]


(Apologies if you receive this more than once.  I am sending it to each list
that is relevant to the topic, in order to make sure the community is aware of
the opportunity and need for comment.  /d)

Folks,

The enclosed announcement is solicits comments on "Email Submission:
Access and Accountability" a modest BCP for basic guidance about an aspect of
email service.  (Pretty versions of the document are available at
<http://bbiw.net/recent.html#spamops>.)

The IESG needs to hear comments about the utility of this document, with
respect to the operational guidance it provides.

Please consider posting comments, as suggested in the enclosed note, noting
concrete benefits and/or concerns you see for this document.  (By being
concrete, you show that you have read the document and understand it; that
way, the IESG can know that you are offering an informed opinion...)

Thanks.

d/

-------- Original Message --------
Subject: Last Call: draft-hutzler-spamops (Email Submission: Access and
Accountability) to BCP
Date: Wed, 06 Jun 2007 10:32:13 -0400
From: The IESG <iesg-secretary <at> ietf.org>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Arnt Gulbrandsen | 12 Jun 2007 18:38
Favicon

2821bis: received: ... for clause


Hi,

The 'for' production is incorrect as it stands. "Received: .... for 
tony <at> att.comtony <at> att.com; ..." is legal according to 2821. Oops. There 
are 2-3 ways out of this:
  - constrain 'for' to one address
  - introduce a separator:
    - either FWS
    - or "," FWS.

My preference is to constrain it to one address. I cannot remember 
seeing production softwaret that inserts multiple addresses on purpose, 
so IMO this can be classified as an unused feature and dropped. (I 
checked 280k received fields just now and found none.)

Arnt
Permalink | Reply | 9 comments |
headers
Arnt Gulbrandsen | 12 Jun 2007 18:38
Favicon

2821bis: three-digit-and-crlf replies


Hi,

"an SMTP response consists of zero or more lines which start with a 
three-digit number and a hyphen, and then exactly one line which starts 
with a three-digit number and a space". How many people think that's 
correct?

2821 says the space on the final line is optional. "250" CRLF is permitted.

Since every SMTP server I've ever seen sends the space and some text, it 
seems reasonable for 2821bis to say something like "servers SHOULD send 
accompanying text, not just the three-digit response code". I do not 
have a strong opinion on the subject, however. Does anyone else?

Arnt
Permalink | Reply | 6 comments |
headers
Peter J. Holzer | 12 Jun 2007 21:46
Picon
Favicon

Re: 2821bis: three-digit-and-crlf replies

On 2007-06-12 18:38:44 +0200, Arnt Gulbrandsen wrote:
> "an SMTP response consists of zero or more lines which start with a 
> three-digit number and a hyphen, and then exactly one line which starts 
> with a three-digit number and a space". How many people think that's 
> correct?
> 
> 2821 says the space on the final line is optional. "250" CRLF is permitted.

I don't think so. Section 4.2 says:

|                    Formally, a reply is defined to be the sequence: a
|  three-digit code, <SP>, one line of text, and <CRLF>, or a multiline
|  reply (as defined in section 4.2.1).  Since, in violation of this
|  specification, the text is sometimes not sent, clients which do not
|  receive it SHOULD be prepared to process the code alone (with or
|  without a trailing space character). 

To me that means that "250"CRLF is not permitted, but a frequent bug
which clients should handle gracefully.

draft-klensin-rfc2821bis-04 contains the same two sentences.

> Since every SMTP server I've ever seen sends the space and some text, it 
> seems reasonable for 2821bis to say something like "servers SHOULD send 
> accompanying text, not just the three-digit response code".

The second sentence might be removed if this "violation of this
specification" is now so infrequent as to be negligible (I also cannot
think any server which returns only bare return codes, but that's hardly
evidence). OTOH, urging implementors to caution never seems wrong to me.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Arnt Gulbrandsen | 12 Jun 2007 22:15
Favicon

Re: 2821bis: three-digit-and-crlf replies


Peter J. Holzer writes:
> I don't think so. Section 4.2 says:
>
> |                    Formally, a reply is defined to be the sequence: a
> |  three-digit code, <SP>, one line of text, and <CRLF>, or a multiline
> |  reply (as defined in section 4.2.1).  Since, in violation of this
> |  specification, the text is sometimes not sent, clients which do not
> |  receive it SHOULD be prepared to process the code alone (with or
> |  without a trailing space character).
>
> To me that means that "250"CRLF is not permitted, but a frequent bug 
> which clients should handle gracefully.

2821 has this grammar:

       Reply-line = Reply-code [ SP text ] CRLF

draft-klensin has this:

    Reply-line     = *( Reply-code "-" [ text ] CRLF )
                   Reply-code [ SP text ] CRLF

The text you quite indicates "Reply-code SP [ text ] CRLF", at least 
when I read it, but the grammar puts the SP inside the optional part in 
both cases.

Arnt
(Continue reading)

Permalink | Reply | 4 comments |

Gmane