🚀 go-pugleaf

In article <v02140404accc14e4adb2@[158.152.8.10]> Alan Staniforth (alan@bones.demon.co.uk) wrote:

> Thanks for the reply aDe. I hadn't looked on that as saying it was
> forbidden to pass on the envelope information (by my reading of RFC 822 the
> envelope is not a header it defines.) I suppose though that the absolute
> prohibition on the use of RCPT
> TO:<@domain1.com,@domain2.com:user@domain3.com> makes it useless
> information anyhow.

Indeed. Section 5.2.6 discusses RCPT TO: and says that source routes
shouldn't be used in that part of the envelope. It also says that the
intention is to abolish source routing, so it is fairly pointless to
supply it in the MAIL FROM: part of the envelope.

Tom

-- 
Tom Hughes (tom@compton.demon.co.uk)
13 Priory Close, Hoddesdon, Herts EN11 8DB
...Don't hit the keys so hard, it hurts.

In article <19951112.230902.14@compton.demon.co.uk>, Tom Hughes
<tom@compton.demon.co.uk> writes

>> Thanks for the reply aDe. I hadn't looked on that as saying it was
>> forbidden to pass on the envelope information (by my reading of RFC 822 the
>> envelope is not a header it defines.) I suppose though that the absolute
>> prohibition on the use of RCPT
>> TO:<@domain1.com,@domain2.com:user@domain3.com> makes it useless
>> information anyhow.
>
>Indeed. Section 5.2.6 discusses RCPT TO: and says that source routes
>shouldn't be used in that part of the envelope. It also says that the
>intention is to abolish source routing, so it is fairly pointless to
>supply it in the MAIL FROM: part of the envelope.

If mail arrives at your machine with a source route in the MAIL FROM: it
seems to us that it is necessary for you to send the mail onward with
that source route intact. Presumably the machines which have handled the
mail so far have put the source route there for a reason, and you may be
breaking the return path if you alter it at all!

If mail arrives at your machine with a source route in the MAIL TO: then
you have a choice. Either you do the 821 relay function (which involves
moving one element of the path from TO to FROM) or you attempt to
deliver directly to the rightmost address ... ie you take no notice of
the source route. In this latter case you do should not be updating the
reverse path.

You might care to note that the current documentation of Demon's "mail
forwarding" service explicitly states that the mail will be rewritten at
Demon into a source route format!

Remember when commenting further (I always seem to be saying this) you
cannot read 821 (or indeed many other RFCs) without having 1122 or 1123
open beside you! Also, everyone quoting 822 (which refers to headers)
rather than 821 (SMTP envelopes) has missed the point entirely :-)

-- 
richard                      Richard Clayton         T U R N P I K E  Ltd
                                                     tel: +44 1306 747747
"Assembly of Japanese bicycle require great peace of mind" quoted in ZAMM

In article <XuD6emB5W2pwEAgT@turnpike.com> Richard Clayton (richard@turnpike.com) wrote:

> If mail arrives at your machine with a source route in the MAIL FROM: it
> seems to us that it is necessary for you to send the mail onward with
> that source route intact. Presumably the machines which have handled the
> mail so far have put the source route there for a reason, and you may be
> breaking the return path if you alter it at all!

I presume Demon still pass on any source route that already existed, but
don't add any of their own... Maybe not though.

> You might care to note that the current documentation of Demon's "mail
> forwarding" service explicitly states that the mail will be rewritten at
> Demon into a source route format!

Does anyone know if this is still happening with the new software
on the punts? Only this was actually preventing Archimedes KA9Q
users from using mail forwarding, as it can't cope with the source
routed address.

> Remember when commenting further (I always seem to be saying this) you
> cannot read 821 (or indeed many other RFCs) without having 1122 or 1123
> open beside you! Also, everyone quoting 822 (which refers to headers)
> rather than 821 (SMTP envelopes) has missed the point entirely :-)

I was quoting from 1123 though... Specifically from the section 
which discusess the envelope.

Tom

-- 
Tom Hughes (tom@compton.demon.co.uk)
13 Priory Close, Hoddesdon, Herts EN11 8DB
...FATAL ERROR: User Executed

In article <19951113.163343.76@compton.demon.co.uk>,
tom@compton.demon.co.uk (Tom Hughes) wrote:

[...]
> I presume Demon still pass on any source route that already existed, but
> don't add any of their own... Maybe not though.
[...]
> Does anyone know if this is still happening with the new software
> on the punts? Only this was actually preventing Archimedes KA9Q
> users from using mail forwarding, as it can't cope with the source
> routed address.

I am fairly sure that they no longer do.  AddMail always shows the 
source route in one of its monitor windows and until the last two or 
three days you would usually see at least one hostname to the left of 
the colon.  The current software must be dropping this information (or 
not deriving it.)

While I can see the reasoning, couldn't a case be made that 1123's 
strictures seem to apply to the RCPT TO: command only and that a 
source path supplied in the MAIL FROM: ought to be preserved and 
forwarded for compatibility, in case older software that expects a 
reverse path to be available is encountered down stream.

The change isn't causing me any problems (in fact it has removed a 
very minor one) but I was a little curious.  Having followed a kind 
pointer by aDe to draft-ietf-drums-smtpupd-00.txt I find myself a 
little more puzzled.  This seems to be working mostly from 821, not 
1123 and in section 4.4 says:

  (i)  a gateway from SMTP->elsewhere SHOULD insert a return-path
  header, unless it is known that the "elsewhere" transport
  also uses Internet domain addresses and maintains the
  envelope sender address separately.

and then:

  -------------------------------------------------------------
  
     Example of Return Path and Received Time Stamps
  
  Return-Path: <@GHI.ARPA,@DEF.ARPA,@ABC.ARPA:JOE@ABC.ARPA>   

which appears to be an explicit violation of the section 5.2.19 which 
aDe quoted as it is placing a source path in an RFC 822 header.

-Alan.

-- 
Alan Staniforth ** alan@bones.demon.co.uk ** alan_s@cix.compulink.co.uk
"Meum est propositum/In taberna mori,/Ut sint vina proxima/Morientis ori."
       -- Anon.

In article <lAoUlcAYyIqwEAdd@turnpike.com>
           richard@turnpike.com "Richard Clayton" writes:

> It is extremely unlikely indeed that your mail is turning up at Demon
> with a source route in the return path. Any source routes which you were
> seeing before were almost certainly being added by the demon system. The
> demon system is perfectly entitled not to do this but to deliver to the
> final destination if it can. In such circumstances you will not see a
> source route.

Did I sleep through some announced change?  In checking my logs I see that 
these stopped dead at the end of October.  After some time early on 
October 31st the presence of "From: @" went from near 100% to zero.  What 
was changed at that time or was this alone the change?

The previous need for adding wildcard matching in mailkill of Phil Karn's 
NET has been greatly reduced.

Regards,
-- 
   Tony - G3SKR / AA2PM                  email: tgold@panix.com
                                                tgold@microvst.demon.co.uk
                                        packet: g3skr@n0ary.#nocal.ca.usa.na