Treatment of Return-Path: headers (Re: mlmmj-recieve silently

Treatment of Return-Path: headers (Re: mlmmj-recieve silently

[Charlie Brady]

On Sat, 21 Jan 2006, Morten K. Poulsen wrote:

> When the mail is "malformed" - e.g. no Return-Path: - we should return 
> EXIT_FAILURE.

Do you have a reference to an RFC which says that Return-Path: is a 
required header? I don't believe that it is required. It's used by 
sendmail (and other MTAs which follow the pattern of sendmail) to record 
the envelope sender, but can't be expected to be provided by all MTAs 
unless it is mandated by an RFC.

In the case of qmail deliveries, the envelope sender is available as 
$SENDER.

> The problem here is that we fork() to make sure that we are not 
> killed by the mail daemon who spawned us.

In the case of .qmail delivery, from the examples I've seen, the -F flag 
will be used to avoid forking.

I suspect this behaviour is wrong anyway. We can't just assume that the 
mlmmj-send completed - the system might be shut down before it's done its 
work, for instance. The LDA shouldn't return a delivery completed status 
until the delivery is completed. This might mean that in rare 
circumstances the delivery is done twice, but it should ensure that the 
message is never lost.

Re: Treatment of Return-Path: headers (Re: mlmmj-recieve silently

[Michael Fleming]

On Fri, 20 Jan 2006 22:23:15 -0500 (EST). Charlie Brady waffled thusly:

> 
> On Sat, 21 Jan 2006, Morten K. Poulsen wrote:
> 
> > When the mail is "malformed" - e.g. no Return-Path: - we should return 
> > EXIT_FAILURE.
> 
> Do you have a reference to an RFC which says that Return-Path: is a 
> required header? I don't believe that it is required. It's used by 
> sendmail (and other MTAs which follow the pattern of sendmail) to record 
> the envelope sender, but can't be expected to be provided by all MTAs 
> unless it is mandated by an RFC.

RFC 2822 Section 3.6.7. (Trace fields)

...and

RFC 822 Section 4.1 (Syntax)

I've never seen a modern MTA that doesn't implement and use it, it's not
specific to Sendmail.

Michael.

-- 
Michael Fleming <mfleming@enlartenment.com>
"Bother" said the Borg, "We've assimilated Pooh!"

Re: Treatment of Return-Path: headers (Re: mlmmj-recieve silently

[Charlie Brady]

On Sat, 21 Jan 2006, Michael Fleming wrote:

> On Fri, 20 Jan 2006 22:23:15 -0500 (EST). Charlie Brady waffled thusly:
>
>> On Sat, 21 Jan 2006, Morten K. Poulsen wrote:
>>
>>> When the mail is "malformed" - e.g. no Return-Path: - we should return
>>> EXIT_FAILURE.
>>
>> Do you have a reference to an RFC which says that Return-Path: is a
>> required header? I don't believe that it is required. It's used by
>> sendmail (and other MTAs which follow the pattern of sendmail) to record
>> the envelope sender, but can't be expected to be provided by all MTAs
>> unless it is mandated by an RFC.
>
> RFC 2822 Section 3.6.7. (Trace fields)
>
> ...and
>
> RFC 822 Section 4.1 (Syntax)

Yes, those RFCs do mention an *optional* Return-Path header. Optional is 
mutually exclusive with "mandatory'.

> I've never seen a modern MTA that doesn't implement and use it, it's not
> specific to Sendmail.

Well qmail does implement it but doesn't use it, so there's one counter 
example. But since the header isn't mandated, it's not safe to assume that
will exist for every MTA. One of the stated goals of mlmmj is mail server 
independence, so it should be very careful about strict RFC compliance.

Mail messages lacking a Return-Path header are still in strict compliance 
with RFC2822.

---
Charlie

Re: Treatment of Return-Path: headers (Re: mlmmj-recieve silently discarding messages

[Mads Martin Joergensen]

* Charlie Brady <charlieb@budge.apana.org.au> [Jan 21. 2006 20:03]:
> >I've never seen a modern MTA that doesn't implement and use it, it's not
> >specific to Sendmail.
> 
> Well qmail does implement it but doesn't use it, so there's one counter 
> example. But since the header isn't mandated, it's not safe to assume that
> will exist for every MTA. One of the stated goals of mlmmj is mail server 
> independence, so it should be very careful about strict RFC compliance.

Sure, but it's possible for every MTA to be configured to add it, and
I'd much rather use that one than To: in the mail message.

-- 
Mads Martin Joergensen, http://mmj.dk
"Why make things difficult, when it is possible to make them cryptic
 and totally illogical, with just a little bit more effort?"
                                -- A. P. J.

Re: Treatment of Return-Path: headers (Re: mlmmj-recieve silently

[Charlie Brady]

On Sat, 21 Jan 2006, Mads Martin Joergensen wrote:

> * Charlie Brady <charlieb@budge.apana.org.au> [Jan 21. 2006 20:03]:
>>> I've never seen a modern MTA that doesn't implement and use it, it's not
>>> specific to Sendmail.
>>
>> Well qmail does implement it but doesn't use it, so there's one counter
>> example. But since the header isn't mandated, it's not safe to assume that
>> will exist for every MTA. One of the stated goals of mlmmj is mail server
>> independence, so it should be very careful about strict RFC compliance.
>
> Sure, but it's possible for every MTA to be configured to add it, ..

You can't say that, because you can't possibly know about all MTAs which 
currently exist or which might exist in the future. But you are right, it 
will usually be possible to find a way to provide it. In qmail, for 
example, it can be provided by using the command "preline", albiet at the 
cost of running an extra process.

> and I'd much rather use that one than To: in the mail message.

I presume you mean From:.

Re: Treatment of Return-Path: headers (Re: mlmmj-recieve silently

[Charlie Brady]

On Sat, 21 Jan 2006, Charlie Brady wrote:

> On Sat, 21 Jan 2006, Michael Fleming wrote:
>
>> I've never seen a modern MTA that doesn't implement and use it, it's not
>> specific to Sendmail.
>
> Well qmail does implement it but doesn't use it, so there's one counter 
> example.

exim is another. It needs the return_path_add transport option set before 
it will add a Return-Path header.

Re: Treatment of Return-Path: headers (Re: mlmmj-recieve silently discarding messages

[Morten K. Poulsen]

* Charlie Brady <charlieb@budge.apana.org.au> [Jan 21. 2006 20:15]:
> > > One of the stated goals of mlmmj is mail server independence, so
> > > it should be very careful about strict RFC compliance.
> >
> > Sure, but it's possible for every MTA to be configured to add it, ..
> 
> You can't say that, because you can't possibly know about all MTAs which 
> currently exist or which might exist in the future. But you are right, it 
> will usually be possible to find a way to provide it.

OK. The interface between the MTA and the MDA is - as far as I know -
not defined in any RFC. Please correct me, if I am wrong. Therefore we
CANNOT know how EVERY MTA will be passing us the envelope information.
It can be some environment variables, added headers, written to
inhireted open file descriptors, as X Window Events, whatever...

If you know a way to make sure that we - inspite of having NO RFC - can
make sure that we get that info from any current or future MTA... Please
send us the patch ;-)

Morten

-- 
Morten K. Poulsen <morten@afdelingp.dk>