[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] Changes to post

From: Ken Hornstein
Subject: Re: [Nmh-workers] Changes to post
Date: Mon, 12 Mar 2012 19:32:23 -0400

>  | There is one wrinkle: Right now Envelope-From: can be blank; if you
>  | do that, then you will get a MAIL FROM:<>, which is useful if you
>  | don't want any bounces at all.  Sounds like the logic should be if
>  | you have multiple From: addresses then Envelope-From: cannot be
>  | blank.
>There's no reason for that, there's no requirement that the smtp sender
>(envelope) address be anything in particular, without regard to what's
>in the From: field, nor whether or not there's a Sender field.

I think you've misunderstood me; in this particular instance, Paul's
proposal was to generate a Sender: header if there were multiple
From: addresses and there wasn't one already.  In this case it would
take it from the Envelope-From: header.  So in _this_ case, the
Envelope-From couldn't be blank because the generated Sender: field 
would be blank.  More of a note to myself, really.

>It might be worth making sure it is only ever blank by deliberate action
>however, rather than just because some other function couldn't produce
>any data.

I think I do that now.

>But resurrecting that discussion isn't
>what I intended, rather perhaps to consider what would be required using
>the new mail submission protocol, which I suspect is supported by just
>about all rational MTAs these days.

Do you mean RFC 6409?  AFAIK, we're compliant with that.  If you
mean something else (or I am wrong), then please let me know.

>With proper use of that (sometime
>in the future perhaps) many of the problems that we're having difficulty
>handling should just go away - eg: as typically used these days, we
>cannot expect nmh to be able to work out a valid mailbox address for
>anyone - so we're more or less requiring the users to set it.  On the
>other hand, an MTA receiving a message through a properly authenticated
>submission session should have no problem with this at all.

In my experience with SMTP AUTH, while you can configure mailers to
require authentication and that information is logged, it doesn't
change anything else with with regards to the SMTP protocol or
message contents.  E.g. even though I authenticate to my mail server
using SMTP AUTH, if I try an unqualified MAIL FROM command (e.g.,
MAIL FROM:<kenh>) that command is rejected.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]