Hello Stephen. Sorry for the late reply, i did not get near to the computer yesterday evening.
Stephen Isard wrote in <[email protected]>: |There was time when (ancestors of?) s-nail would dependably expand a |plain username to username@hostname, where hostname was the machine or This is done by MTA if you do not do anything. |domain that you were sending from. If I run s-nail locally, with mta |defaulting to /usr/lib/sendmail, I get that behavior - maito to myname |gets sent to myname@localmachine. Yes. You also get that from the MUA if you place a locally valid username in <> angle brackets due to Viktor's request: $ </dev/null s-nail -:/ -Smta=test -Sfrom='<steffen>' -s t $LOGNAME ... Author: steffen@kent From: steffen@kent ... |And I have access to a machine running the ancient mailx 12.5 where the |(obsolete on s-nail) variable smtp is set to "smtp.mydomain" and a Now mta= (and covering more cases under its umbrella). |message to myname successfully gets sent to myname@mydomain. Hm. Really? I do not remember this, i had to look. |However, with s-nail and an account where I am logged in as |myname@mydomain, with the mta variable set to "smtp://smtp.mydomain", an |attempt to send to myname gets me "user name (MTA alias) targets are not |allowed".[.] Yes, we disallow plain names as "usually" SMTP/SUBMISSION receivers need to be full aka real email addresses. Ie we try to prevent locale user errors, assuming the email would (in parts) "bounce back". (Ie you normally get an email on "the back channel" which states "mail could not be delivered to".) |[.] I've tried some experiments with expandaddr and smtp-hostname |without success. I don't actually understand the man page sections |about them. Hopefully the manual is better with v14.10, it underwent a massive rewrite (not yet completed). Hm. Now i need a clarification myself. It is not about yourself, it is about a receiver address? Because $ </dev/null s-nail -:/ -Smta=smtp://du.da -d -s t ha@du ... s-nail: >>> MAIL FROM:<steffen@kent> BODY=7BIT s-nail: >>> RCPT TO:<ha@du> That works for me also in v14.9.25. I see. It is that: $ </dev/null mailx -:/ -Smta=smtp://du.da -d -Sexpandaddr -s t ha .. mailx: ha: user name (MTA alias) targets are not allowed mailx: Some addressees were classified as "hard error" Yes, i changed that; it is even documented for *exandaddr* ‘name’ [sets free] user names still unexpanded after alias† and mta-aliases† processing, and thus left for expansion by the mta† (invalid for the built-in SMTP one), So in short what you are asking for is a way to allow plain user names also in the SMTP code path. I see. Hmm if i try that (coming to that like a virgin) i get $ telnet vpn 25 ... MAIL FROM:<steffen> RCPT TO:<steffen> 250 2.1.5 Ok ... 250 2.0.0 Ok: queued as CE52316061 that becomes From [email protected] Thu Dec 12 18:01:02 2024 Return-Path: <[email protected]> X-Original-To: steffen Delivered-To: [email protected] ... So yes, that really seems to work (at least in this easy situation). What if i add "smtpname" for v14.10? I really want that to be explicit. Now one would have to think whether we should allow only matching (sub?) domains, then, as you say!?!, or whether MTA alias processing on the SMTP MTA side should still be assumed. I *think*, after only this five minute excurse, that this seems favourable if an explicit "smtpname" setting is introduced, real MTAs would do this, and i would constrain explicit user setting if i would not? What do you say? Thank you, Ciao Stephen!! --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) | |And in Fall, feel "The Dropbear Bard"s ball(s). | |The banded bear |without a care, |Banged on himself for e'er and e'er | |Farewell, dear collar bear
