[EMAIL PROTECTED] (David Stern) writes: > Hi, > > I'm trying to beat smail down with a stick, am having a little trouble > (actually more than a little). Would somebody *PLease* translate into > English this brief /etc/smail/config snippet and answer three questions? > > from_field="From: \ > ${if def:ident_sender\ > [EMAIL PROTECTED] > {$sender${if def:sender_name: ($sender_name)}}}" > > (My interpretation: "look at the From: line (or Sender: line, which?), > and if the sender's "identification code" (whatever that means) is > non-null (exists), then rewrite that line (which one: From: or Sender: > ?) to look like .. here it breaks down, and that extra condition in the > last line confuses me.)
My interpretation is that smail only makes use of the from_field variable if incoming mail has no "From:" or "Sender:" fields already; further, if there is a From: field already, then smail inserts a "Sender:" field using the from_field information only if the pre-existing From: field doesn't match what smail would have written with from_field. > 1.) What is the difference between the roles of Sender:, Return-path:, > and From: lines and are each required according to RFC's? (It was my > understanding that there was some contention as to whether the Sender: > line was required, but that it was desirable because it acts as an > "envelope", which is a good thing for some MTA's and MUA's. I'm not > clear about the roles of Return-path:, From:, and Sender: or which are > required.) Ok - the idea is that the From: line should be the email address of the person the mail is from, whereas the Sender: is the email address of the account the mail is from, if that's different. (Sender: headers are not required if the From: address also represents the account the mail comes from). Return-path: headers I don't quite understand; from what I can tell, they're used at this point mostly for automated error messages, and should only be inserted by the final MTA in the mail delivery process. What doesn't make sense about this to me is that often the last MTA may not have a clue as to how to go about returning mail, whereas the first MTA in the process has a chance of knowing how to get back to itself. Perhaps this makes more sense in a UUCP environment. > 2.) Why does "from_field" require it begin "From:" (as shown in the man > page below) and does "from_field" rewrite the "From:" line, or the > "Sender:" line and how does it decide? (It seems ambiguous.) I think there are historic reasons (before from_field was used for "Sender:" fields) for having it begin with "From:". > 3.) How can I find out what ident_sender, as well as all other > variables, are assigneded as? (I need to know so I can test what is > happening; e.g.: when I set visible_name to u.washington.edu, and > restart smail and inetd or reboot, there is no change, but I don't know > why. I've tried echoing and mailing the variables, but I must be doing > it wrong.) The best thing I can think of is a transport using the pipe driver. Try adding the following to your /etc/smail/routers (before any smarthost directive, of course): match-fake-diag-addrs: driver=gethostbyname, transport=diagnosticpipe; required=diagnostic Then add the following (anywhere) to your /etc/smail/transports file: diagnosticpipe: driver = pipe; cmd = "/etc/smail/diagnostic.pl ${if def:ident_sender \ {$ident_sender} {no_ident_sender}} ${if \ origin:local {origin:local} {origin:remote}}", umask = 0022 You can add arguments to the cmd above if there's anything else you want to find out about that isn't already shown in the environment. Then, make the following short perl script /etc/smail/diagnostic.pl (and make it executable): #!/usr/bin/perl open(STDOUT, ">/tmp/smaildiag.$$"); $| = 1; foreach (@ARGV) { print "argument: $_\n"; } print "---env:\n"; system("env"); print "--stdin:\n"; system("cat"); Finally, add the following line to your /etc/hosts file: 192.68.42.47 dummyhost.diagnostic Now, any mail sent to [EMAIL PROTECTED] will get logged to a file of the form /tmp/smaildiag.* Now, one strong word of caution: I've been trying this, and can't get it to work, quite - apparently (at least with the smail I have), it's an expansion error to include a ${if ... } clause in the cmd attribute - yes, I know this doesn't make sense, but apparently it's true. (why smail would use different string expansion rules in different places and NOT DOCUMENT IT is beyond me.) Maybe, though, it's just a bug in my 3.2-3 smail. (I hope so, because it's certainly broken behavior) I can get it to work if I cut out all the if clauses. (Well actually, it then only works when it should according to the documentation - that is, "/etc/smail/diagnostic.pl $ident_sender" works only when ident_sender is defined) If smail 3.100 has similar problems, that could explain why things aren't working well, if you have a ${if ... } expansion in an insert_header or remove_header line. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .