Re: new hamm nmh breaks header rewriting, isp becomes irate
On Sun, 22 Feb 1998 17:43:39 EST, wrote:
[EMAIL PROTECTED] (David Stern) writes:
The most likely explanation is that nmh has started adding Sender:
lines; this is in general a good thing - we just need to be careful to
take them out or rewrite them nicely on the way out. It may be that
some machines are rejecting your mail for having sender lines with two
@ signs in them. In that case, a kludge to fix it is to change the
line that adds the sender stuff to:
insert_header=Sender: \
${if def:ident_sender \
[EMAIL PROTECTED]@$visible_name}}
This, combined with the remove_header line above, should get things
back to the way they were.
This idea sound effective, but I had problems getting smail to take
this, probably because I'm not putting it in the correct place -- where
exactly does this go?
Hmm... Sender headers really shouldn't be rewritten like this if they
already exist... Perhaps something like:
from_field=From: \
${if def:ident_sender \
[EMAIL PROTECTED] \
{$sender${if def:sender_name: ($sender_name)}}}
in /etc/smail/config and then nothing dealing with Sender: headers in
the transports file (neither adding or removing) would be better.
This sounds more artful, and I think I sort of got this to work (it's
as good as it was before, at least -- more on this in a second).
There's a double quote missing from the end. Thanks, Daniel.
You may also want to ensure that the visible_name used is something
other than localhost, which is what it appears to be set to.
Unfortunately, the only way I've found to do that (without having a
name registered with .dyn.ml.org) is to rewrite /etc/smail/config each
time ip-up is called. (There's one way of doing that on my webpage
http://www.math.jhu.edu/~martind/mybox.html - after I wrote that page
I figured out a cleaner method using m4)
I thought I only needed that set visible_hostname to my dynamically
assigned IPA if I needed to be able to be contacted directly there. I
see one potential conflict with setting my visible_hostname to my
dynamically assigned IPA, and that would be depending on how smart my
smarthost is, bounced mails, as sometimes occur for reasons other than
my Sender: line, may be bounced to my isp after I disconnect, and right
now, that would be a bad thing. I know that the visible_hostname,
mx[1-4].u.washington.edu, set by allowing the default set at runtime
works for mail delivery, because I've tried it, but the dynamically
assigned IPA I'd get would be much different (something like
cs_student_XXX.washington.edu), and I'm afraid to test that, because my
isp is irate with me right now. What exactly do the RFC's say about
this?
(One of these days I'm just going to get fed up and write a mailer
designed for dialup systems which need to rewrite headers on the way
out and may well have no consistent name - the wonders of free
software that I won't have to start from scratch...)
I don't know why there aren't provisions made for this in the
traditional MTA's, because dialup networking is probably one of the
most common types of internet connections now. This should be standard.
I really appreciate your help. It'd have taken me eons to figure this
out alone. Thanks, Daniel.
--
David Stern
--
http://weber.u.washington.edu/~kotsya
[EMAIL PROTECTED]
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: new hamm nmh breaks header rewriting, isp becomes irate
Daniel Martin writes: You may also want to ensure that the visible_name used is something other than localhost, which is what it appears to be set to. Unfortunately, the only way I've found to do that (without having a name registered with .dyn.ml.org) I've got a name, but my isp still bounces my mail if I use it, accusing me of attempting to use them as a relay. ...is to rewrite /etc/smail/config each time ip-up is called. I found that setting visible_name to my isp's domain works: visible_name=win.bright.net (my popmail address is [EMAIL PROTECTED]). One of these days I'm just going to get fed up and write a mailer designed for dialup systems which need to rewrite headers on the way out and may well have no consistent name... What does Win95 do? -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: new hamm nmh breaks header rewriting, isp becomes irate
[EMAIL PROTECTED] writes: Daniel Martin writes: You may also want to ensure that the visible_name used is something other than localhost, which is what it appears to be set to. Unfortunately, the only way I've found to do that (without having a name registered with .dyn.ml.org) I've got a name, but my isp still bounces my mail if I use it, accusing me of attempting to use them as a relay. It's behavior like this that really gets me annoyed with spammers - things would be so much easier if people with mail servers didn't have to take these paranoid attitudes. ...is to rewrite /etc/smail/config each time ip-up is called. I found that setting visible_name to my isp's domain works: visible_name=win.bright.net I suppose this works; my problem with it is that then some mail messages generated locally will appear to have come from some account at your isp - I suppose this isn't usually something to worry about, but it just doesn't seem clean... One of these days I'm just going to get fed up and write a mailer designed for dialup systems which need to rewrite headers on the way out and may well have no consistent name... What does Win95 do? In general, it makes a lot of assumptions that a machine with a multiuser OS can't. In fact, the role smail fills simply doesn't exist on (most) Win '95 boxes - there is no MTA, and the MUA does both collection (from pop or imap boxes) and delivery. (Much in the way that pine might be used on a unix system without any smtp program). Win95 also never has to worry about local mail. (with only one user, where's it gonna go?) I'm drawing up a list of how I'd like a mail program to behave in my environment; so far, these are the requirements: Local mail is just delivered locally; no fuss or hassle about forwarding local mail on to one's ISP unless that's very explicitly requested. Headers (including the RFC822 envelope) are rewritten transparently and accurately. This means that, for example, Sender: lines from my machine would become something like [EMAIL PROTECTED] (i.e. the Sender: line would depend on the dns name of the ip address the message leaves the machine by), and that the From: line would match the envelope address, if the From: line was requested to be rewritten. Access to outgoing mail can be restricted for certain users; however, postmaster can opt to receive each bounced message and ok certain messages for delivery to the rest of the world. Another machine/other machines can be treated as local, and not subject to the rewritting rules. Mail relaying... I'm not certain what I'd want the behavior to be in this case - probably just disallow relaying entirely, except to/from local machines. Can anyone else think of other features the ideal MTA for dialup machines should have? -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: new hamm nmh breaks header rewriting, isp becomes irate
Daniel Martin wrote: I'm drawing up a list of how I'd like a mail program to behave in my environment; so far, these are the requirements: Local mail is just delivered locally; no fuss or hassle about forwarding local mail on to one's ISP unless that's very explicitly requested. Headers (including the RFC822 envelope) are rewritten transparently and accurately. This means that, for example, Sender: lines from my machine would become something like [EMAIL PROTECTED] (i.e. the Sender: line would depend on the dns name of the ip address the message leaves the machine by), and that the From: line would match the envelope address, if the From: line was requested to be rewritten. My zyxel router automatically connects to the net whenever it needs to send a packet off the local lan. The router then gets a dynamic address and uses a form of network address translation that zyxel calls SUA to hide the internal network. Currently the only way to get the ip address is through a telnet or serial connection to the router. I think expect would let me navigate through the menus to get the ip address automatically, but the address would only be valid when the isdn line is up. If I send mail while the line is down, the mail itself brings the line up. This is too late to modify the message. I really like your idea. I've had quite a few problems getting local and remote mail to work with smail and a dialup connection. Access to outgoing mail can be restricted for certain users; however, postmaster can opt to receive each bounced message and ok certain messages for delivery to the rest of the world. Another machine/other machines can be treated as local, and not subject to the rewritting rules. Mail relaying... I'm not certain what I'd want the behavior to be in this case - probably just disallow relaying entirely, except to/from local machines. Can anyone else think of other features the ideal MTA for dialup machines should have? -- Lee Bradshaw [EMAIL PROTECTED] (preferred) Next Level Communications[EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
new hamm nmh breaks header rewriting, isp becomes irate
Hi, Recently I upgraded nmh on hamm from 0.17-1 to 0.22-1 and I just discovered my smail header rewriting is broke, and I think the new nmh is the culprit. smail remains on hold status in dselect. I've read the bug reports (there are none), I've read /usr/doc/nmh/DIFFERENCES.gz, but there is no mention of this. My isp has become irate. This is causing a lot of grief for a lot of people, and I hope the nmh package maintainer will please be far more considerate in the future. Since my mail will bounce from just about anywhere but the debian list, I can't very well send this to the nmh package maintainer right now, but you can trust that I will when this is fixed. Where can I get the nmh deb that works, 0.17-1 ? -- David Stern -- http://weber.u.washington.edu/~kotsya [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: new hamm nmh breaks header rewriting, isp becomes irate
[EMAIL PROTECTED] (David Stern) writes: Hi, Recently I upgraded nmh on hamm from 0.17-1 to 0.22-1 and I just discovered my smail header rewriting is broke, and I think the new nmh is the culprit. smail remains on hold status in dselect. I've read the bug reports (there are none), I've read /usr/doc/nmh/DIFFERENCES.gz, but there is no mention of this. My isp has become irate. This is causing a lot of grief for a lot of people, and I hope the nmh package maintainer will please be far more considerate in the future. Since my mail will bounce from just about anywhere but the debian list, I can't very well send this to the nmh package maintainer right now, but you can trust that I will when this is fixed. Where can I get the nmh deb that works, 0.17-1 ? How is it broken? I'm trying to imagine what nmh is doing that could cause the header-rewriting to fail (unless nmh is trying to bypass smail completely). The only thing I can think is that nmh has started to append @mailhostname to your email address as it's going out. To test this, here's something you can do: Take your net connection down, and if you're using diald do a force down to keep it down. Then, send a message with nmh to any address. Now, do a: tail /var/log/smail/logfile and look at the second-to-last entry - it should start with Received FROM: and then give the name as handed to it by nmh. For example, suppose that nmh is now sending From: lines that look like [EMAIL PROTECTED] - You can then add the following to your /etc/smail/maps/frommap: [EMAIL PROTECTED] [EMAIL PROTECTED] I know, it's annoying to have to add a new line to frommap each time some program decides to pass your address along a slightly different way, but the whole smtprewriter thing is just a big giant hack anyway. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: new hamm nmh breaks header rewriting, isp becomes irate
On Sun, 22 Feb 1998 08:58:15 EST, wrote: [EMAIL PROTECTED] (David Stern) writes: Recently I upgraded nmh on hamm from 0.17-1 to 0.22-1 and I just discovered my smail header rewriting is broke, and I think the new nmh is the culprit. smail remains on hold status in dselect. I've read the bug reports (there are none), I've read /usr/doc/nmh/DIFFERENCES.gz, but there is no mention of this. [..] Where can I get the nmh deb that works, 0.17-1 ? How is it broken? I'm trying to imagine what nmh is doing that could cause the header-rewriting to fail (unless nmh is trying to bypass smail completely). The only thing I can think is that nmh has started to append @mailhostname to your email address as it's going out. To test this, here's something you can do: [..] I'd already done what you told me, and everything looks fine. Heres the entry for this (original) post (this am): -- Received FROM:[EMAIL PROTECTED] HOST:localhost [127.0.0.1] PROTOCOL:esmtp PROGRAM:smail SIZE:1460 IDENT:kotsya ID-METHOD:rfc1413 destination supports esmtp 8BITMIME PIPELINING Delivered VIA:debian.novare.net TO:debian-user@lists.debian.org ORIG-TO:debian-user@lists.debian.org ROUTER:inet_hosts TRANSPORT:smtprewriter Completed. --- Now here's a log entry for a similar post a week ago (Feb 16): --- Received FROM:[EMAIL PROTECTED] HOST:localhost [127.0.0.1] PROTOCOL:esmtp PROGRAM:smail SIZE:1556 IDENT:kotsya ID-METHOD:rfc1413 destination supports esmtp 8BITMIME PIPELINING Delivered VIA:debian.novare.net TO:debian-user@lists.debian.org ORIG-TO:debian-user@lists.debian.org ROUTER:inet_hosts TRANSPORT:smtprewriter Completed. --- (so far as I can tell, the only difference is the number of bytes) For some unknown reason my Sender: line is no longer being rewritten, and most destinations will refuse my mail because it is not DNS resolvable (as an aside I'd be interested to hear the basis for such refusals). Those that don't refuse it will modify it, go figure. So far, there's no indication why my headers aren't being rewritten. If you (or anyone) have any more ideas, I'd sure appreciate hearing them. I know, it's annoying to have to add a new line to frommap each time some program decides to pass your address along a slightly different way, but the whole smtprewriter thing is just a big giant hack anyway. While I agree on technical grounds regarding smtprewriter transfer method, I see no reason for nmh to break it. Why can't my mail programs just get along? Where do old .debs go? I need to get an nmh that doesn't break my header rewriting, 0.17-1. I've searched everywhere I can think of and they're not to be found. -- David Stern -- http://weber.u.washington.edu/~kotsya [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: new hamm nmh breaks header rewriting, isp becomes irate
[EMAIL PROTECTED] (David Stern) writes:
For some unknown reason my Sender: line is no longer being rewritten,
and most destinations will refuse my mail because it is not DNS
resolvable (as an aside I'd be interested to hear the basis for such
refusals). Those that don't refuse it will modify it, go figure.
So far, there's no indication why my headers aren't being rewritten.
If you (or anyone) have any more ideas, I'd sure appreciate hearing
them.
Well, I have one more idea - the smtprewriter transport as I have it
on my web page doesn't remove any Sender: header that's already there;
it just adds a new one. So, you'll probably want to add a line of:
remove_header=Sender
before the line that inserts the new sender header.
Looking at your latest reply, there are indeed two Sender: lines.
Looking at those Sender: lines, however, I realize a problem. One
program is setting your Sender: line to [EMAIL PROTECTED] (the Debian
mailing list software is then changing this to
[EMAIL PROTECTED] - interesting effect); another is adding
a Sender: line of [EMAIL PROTECTED]@localhost.localdomain.
The most likely explanation is that nmh has started adding Sender:
lines; this is in general a good thing - we just need to be careful to
take them out or rewrite them nicely on the way out. It may be that
some machines are rejecting your mail for having sender lines with two
@ signs in them. In that case, a kludge to fix it is to change the
line that adds the sender stuff to:
insert_header=Sender: \
${if def:ident_sender \
[EMAIL PROTECTED]@$visible_name}}
This, combined with the remove_header line above, should get things
back to the way they were.
Hmm... Sender headers really shouldn't be rewritten like this if they
already exist... Perhaps something like:
from_field=From: \
${if def:ident_sender \
[EMAIL PROTECTED] \
{$sender${if def:sender_name: ($sender_name)}}}
in /etc/smail/config and then nothing dealing with Sender: headers in
the transports file (neither adding or removing) would be better.
You may also want to ensure that the visible_name used is something
other than localhost, which is what it appears to be set to.
Unfortunately, the only way I've found to do that (without having a
name registered with .dyn.ml.org) is to rewrite /etc/smail/config each
time ip-up is called. (There's one way of doing that on my webpage
http://www.math.jhu.edu/~martind/mybox.html - after I wrote that page
I figured out a cleaner method using m4)
(One of these days I'm just going to get fed up and write a mailer
designed for dialup systems which need to rewrite headers on the way
out and may well have no consistent name - the wonders of free
software that I won't have to start from scratch...)
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
