Gavin Troy <[email protected]> wrote:
 |Steffen Nurpmeso <[email protected]> wrote:
 |I think this is the most natural behaviour.

Careful with the speed limit here.

 |> Could you please confirm this is also fixed for you?
 |
 |Yes from my point of view it all works perfectly.

It's a pity we're too old to never see young Led Zeppelin live on
stage.  In fact all the english Beautés die away ... just think of
Michael Jackson!
And the new big Moto Guzzi is almost as fat as a Harley!

 |>|>|> set password-mail.messagingengine.com:465=PASSWD
 |>|>|
 |>|>|which I think is not the desired behavior.
 |> 
 |> No, as above, i think this will remain a host/port tuple, just as
 |> has been specified.
 |
 |That's fine too. I think you could say either behaviour makes sense.

Tja, it's unbelievable, but now i've crossed the 40 my music is
quieter ... and i'm still able to hear it!

 |> S/MIME uses the value found in From: for signing and verification.
 |> But i still think it makes sense to derive the rest of the user
 |> credentials and anything else from the actual SMTP account.
 |> I think for most people it doesn't make a difference, and there is
 |> always the chance to get to that state by using `account's.
 |> But it is definetely not nice.
 |
 |Yep, I think v15 makes much more sense for this overall.

I really would like to implement an automatic deduction of the
content of From: via the chosen SMTP account, which i think is
what you are asking for, and which i think would be so much more
comfortable and easy, as in from-USER@HOST etc.

Getting extraordinary boring, but the problem is (again) that the
codebase is so loosely connected and reaquires and recomputes
state over and over again.  For *from* we usually come in by
calling myaddrs() (also indirectly via myorigin()), so what can be
so hard in parsing the URL early and simply passing it through to
that, in order to diversify *from.**

  ?1[steffen@sherwood nail.git]$ git grep -E 'myorigin|myaddrs'
  collect.c:      maxlines -= (myaddrs(hp) != NULL || hp->h_from != NULL);
~p tilde command - long before URL evaluation (but who cares here, ok)
  head.c:myaddrs(struct header *hp)
  head.c:myorigin(struct header *hp)
  head.c:   if ((ccp = myaddrs(hp)) != NULL &&
The actual implementation of myorigin()
  head.c:         hp->h_from = lextract(myaddrs(hp), GEXTRA | GFULL);
grab_headers() implementation potentially gets through to *from*
(if GEXTRA is set, which it is at least when calling ~H)
  mime.c:      } else if (_has_highbit(myaddrs(NULL)))
Preparation of MIME part, detection of content-type charset etc. -
long before URL evaluation
  nailfuns.h:FL char const * myaddrs(struct header *hp);
  nailfuns.h:FL char const * myorigin(struct header *hp);
  sendout.c:         ? skin(myorigin(sbp->sb_hp)) : NULL);
_sendbundle_setup_creds(), short before URL evaluation - this
also could be adjusted TODAY (just fine that is)
  sendout.c:         cp = skin(myorigin(NULL)); /* XXX ugh! ugh!! */
-r flag had been used, get fallback.  (Sick anyway.)
  sendout.c:   else if ((h = skin(myorigin(hp))) != NULL && strchr(h, '@') != 
NULL)
Message-Id: creation, oh man
  sendout.c:      if ((cp = myaddrs(NULL)) != NULL) {
Resending.
  sendout.c:      } else if ((addr = myaddrs(hp)) != NULL) {
puthead(): ~p (again!  and mean it!), composing startup 
(headers), editing a mail

So what i could do today is (i think) add this undocumented and
let it happen to happen for the most simple cases.  But that would
be sooo ugly!

The Tiger Lillies sing (Ad Nauseam, Suicide) "so i tried some
pills but all i got was diarrhoea .. and it runs and it runs and
it runs .. so i found su-icide su-icide su-icide .. is for me".
Btw: "there's crap - it's a sickness; there's crap - on TV".
But: "the crack of doom is coming" with v15.0.
At least i hope so.

 |So thanks! It all looks good to me.

Ah ja, i see.

 |Although I want to also comment on the new colour handling: \
 |I must add my TERM,
 |`rxvt-unicode-256color`, to colour-terms. Perhaps the defaults \
 |or logic could
 |be extended (other -256color terms exist).

No longer necessary on [next] -- terminfo rocks, if we find
a $TERM which has "color" in its name colours are auto-enabled.
Cool stuff, thanks Gavin!

(Just in case you haven't seen it yet: *colour-pagers* is gone,
that is now the binary *colour-pager* and off by default, since
less(1) and lv(1) require special flags to interpret them.)

 |Cheers

I'm more with divinely ordained fume however, aaaaand in theory,
barring the paranoia, of course.  -:)
Ciao,

--steffen

------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
S-nail-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/s-nail-users

Reply via email to