Re: diagnosing smail
kotsya@u.washington.edu (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\
> {$ident_sender@$visible_name}\
> {$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 someone@dummyhost.diagnostic 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
debian-user-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: