headers
Valdis.Kletnieks | 10 Aug 2004 19:53
Picon
Favicon

Buglet in RFC3461 - DSN, section 4.2.

(Will the appropriate people please make a note of this for whenever we
turn the crank on 3461 again?)

RFC3461, section 4.2 says:

   The "addr-type" portion MUST be an IANA-registered electronic mail
   address-type (as defined in [3]), while the "xtext" portion contains
   an encoded representation of the original recipient address using the
   rules in section 5 of this document.  The entire ORCPT parameter MAY
   be up to 500 characters in length.

In fact, the encoding rules are in section *4*.  Much hilarity ensued as an MUA
enhancement I was writing failed to escape a '+' because section 5 didn't say
anything about the plus or equals characters, while the section 4 that I didn't
read did say something about escaping them....
Permalink | Reply | 0 comments |
headers
Valdis.Kletnieks | 10 Aug 2004 21:32
Picon
Favicon

Re: Buglet in RFC3461 - DSN, section 4.2.

On Tue, 10 Aug 2004 12:07:41 PDT, you said:

> Is this a request to create an erratum?

(after checking http://www.rfc-editor.org/cgi-bin/errataSearch.pl)

Yes, an erratum there and we collectively remember to fold it in
the next time around looks like the Right Thing To Do....
Permalink | Reply | 0 comments |
headers
Markus Stumpf | 27 Aug 2004 20:34
Favicon

SMTP delivery strategies


A while ago there was a long and emotional discussion on the qmail list
about whether a 5xx should be treated as permanent for the message or
permanent or one server that is in the MX list of the addressed domain.
This originates from the fact that some ISPs don't accept email from
dialup address space and signal a 5xx (permanent) to the sending MTA,
however they mean "we do not accept this message from that IP - try your
ISPs relay SMTP server".

I did some tests with spam honey pots (add backup MX records, because
spammers deliver often to backup MX hosts to circumvent policies at the
best MX and backup MX hosts have usually higher trust at the best MX) and
noticed a lot of different behaviour of various MTAs that tried to backoff
(like some do contact other MX hosts on a 4xx message, others don't).

RFC2821 is not too clear about these strategies and some of the
confusion derives from the fact that there are no clear definitions
e.g. what "delivery" means.

Would it be a good idea/is there any interest in having a kinda BCP
document to get these clarified?

	\Maex

--

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"
(Continue reading)

Permalink | Reply | 2 comments |
headers
Keith Moore | 27 Aug 2004 20:43
Picon

Re: SMTP delivery strategies


 > A while ago there was a long and emotional discussion on the qmail list
> about whether a 5xx should be treated as permanent for the message or
> permanent or one server that is in the MX list of the addressed domain.
> This originates from the fact that some ISPs don't accept email from
> dialup address space and signal a 5xx (permanent) to the sending MTA,
> however they mean "we do not accept this message from that IP - try your
> ISPs relay SMTP server".
> 
...
> 
> Would it be a good idea/is there any interest in having a kinda BCP
> document to get these clarified?

yes, it would be a good idea.

IMHO there's a difference between the meaning of a 5xx response from
an authoritative SMTP server for a recipient domain, and the meaning
of a 5xx response from some random other SMTP server.

but it might also be the case that some 5xx codes should be inherently
assumed to mean "per server" and others assumed to mean "per domain".

Keith
Permalink | Reply | 0 comments |
headers
SM | 28 Aug 2004 21:06

Re: SMTP delivery strategies


Hi Markus,
At 11:34 27-08-2004, Markus Stumpf wrote:
>A while ago there was a long and emotional discussion on the qmail list
>about whether a 5xx should be treated as permanent for the message or
>[snip]
>Would it be a good idea/is there any interest in having a kinda BCP
>document to get these clarified?

It would be a good idea to clarify how 5xx codes should be 
treated.  Content-filtering gateways (for antispam or antivirus) make the 
issue more confusing as they don't always return the correct status 
codes.  A BCP could clarify which codes to use and when to use them.

Regards,
-sm
Permalink | Reply | 0 comments |
headers
Eric Burger | 31 Aug 2004 13:32

Extensions for Reliable Submission of Requests That Take a Long T ime


A problem we face in Lemonade is the client needs to know, with positive
protocol support, that their message submission is being worked on.

The following draft:
http://www.ietf.org/internet-drafts/draft-burger-smtp-rdlv-00.txt
describes one such mechanism for achieving that requirement.  Comments and
better suggestions greatly appreciated.

Another problem we face in Lemonade is that the client is highly likely to
disappear before their message submission completes.

The following draft:
http://www.ietf.org/internet-drafts/draft-burger-smtp-deta-00.txt
describes a method pulled out of thin air.  It is the requirement that is
important to solve.  I am not married to this implementation.

PLEASE, PLEASE, PLEASE discuss the implementations on the ietf-smtp list,
and NOT the Lemonade list.

Requirements can be cross-posted.

NOTE WELL: if you cross post to the Lemonade list and you are not a
subscriber of the Lemonade list, or you include a bunch of people in the To:
and Cc: fields, your message may be delayed for up to a month.
Permalink | Reply | 0 comments |

Gmane