Re: bouncing w/ mutt-1.3.28i
On Fri, Jul 12, 2002 at 09:18:21PM -0500, David T-G wrote: One thing I didn't see revisited was your subscription problem. Are you now subscribed? Do you want to be? I've figured it out now. Worked fine from the new address. When you bounce a message, mutt takes the message as it was received by you and hands it back to sendmail with a new addressee so that sendmail can put it on its way. This is just like a .forward file in that sense (though it's done manually, of course); nothing in the message envelope is changed, and new headers are added. So, does mutt add a Resent-To: header or does it not? If it does, there is evidence that this does not work sometimes. I'm trying to lay my hands on such a message. When you resend a message, all of the transit-related headers (Received:) are thrown away, the identification headers (From:) are available to change as necessary, and the body is wrapped in a new envelope. I'm almost certain that it's completely a new message, with the Message-ID: regenerated on your system, too. Does that mean that mutt won't be able to sort it into the correct thread? All you're doing is using the old message as a template for an entirely new message that happens to look very similar (usually). What is it that you used to do, and what is it that you really want to do? I used to bounce mails and I want to bounce mails. Not that I care what actually happens with the mail, but bouncing a message requires two keystrokes (b type new address ret) while resending requires 12 (esce : w q ret t ctrla k type new address ret y). Hm, can I pass keystrokes into vi with a macro? But at the moment it doesn't look like I can continue to use 'bounce' since the list of Received: headers is getting too long with this mail server. You sound as though you've been doing this for a while, so please forgive the basic level of my explanations and questions, No offense taken. I try to avoid fiddling with the mail system as much as possible, so my knowledge of how mail transport works exactly is limited. but 'b'ouncing hasn't changed since I met mutt at 0.88 and I can't imagine, particularly since it also works the same way in elm, that it was *ever* any different. Well, I belive you. What else could have changed to cause my troubles? BTW, I'd like to setup my mail system to send external mails over a different server than internal ones (because our servers are blacklisted). What mailer would you recommend (exim, sendmail, postfix, ...?) I'm currently using exim. Bye Dominik ^_^ ^_^ -- Dominik Vogt, mail: [EMAIL PROTECTED], phone: 0721/91374-382 Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe
Re: bouncing w/ mutt-1.3.28i
Dominik --
...and then Dominik Vogt said...
%
% On Fri, Jul 12, 2002 at 09:18:21PM -0500, David T-G wrote:
% One thing I didn't see revisited was your subscription problem. Are you
% now subscribed? Do you want to be?
%
% I've figured it out now. Worked fine from the new address.
Yay!
%
% When you bounce a message, mutt takes the message as it was received by
% you and hands it back to sendmail with a new addressee so that sendmail
% can put it on its way. This is just like a .forward file in that sense
% (though it's done manually, of course); nothing in the message envelope
% is changed, and new headers are added.
%
% So, does mutt add a Resent-To: header or does it not? If it does,
% there is evidence that this does not work sometimes. I'm trying
% to lay my hands on such a message.
AFAIK it does, but see the explanations on envelopes and headers in a
sub-thread for more info; they speak from knowledge whereas I speak from
gee, I think it works that way :-)
%
% When you resend a message, all of the transit-related headers (Received:)
...
% with the Message-ID: regenerated on your system, too.
%
% Does that mean that mutt won't be able to sort it into the correct
% thread?
I don't think the References: are tossed, but it's a new message and so
it should get a new Message-ID: and so it changes.
%
...
% What is it that you used to do, and what is it that you really want to
% do?
%
% I used to bounce mails and I want to bounce mails. Not that I
OK.
% care what actually happens with the mail, but bouncing a message
% requires two keystrokes (b type new address ret) while
Yep.
% resending requires 12 (esce : w q ret t ctrla
% k type new address ret y). Hm, can I pass keystrokes into
% vi with a macro? But at the moment it doesn't look like I can
There are lots of ways to handle that. You could set your editor to
something else (/bin/true) for the moment. You could still use vi but
temporarily change $editor to vi +wq %s or the like to automatically
save and exit. You could use the recent patch that lets you define an
esc-e editor separate from your regular editor so you don't have to muck
with temporarily changing things at all.
% continue to use 'bounce' since the list of Received: headers is
% getting too long with this mail server.
That's really odd. Your mail server should let a message go through a
million hops if it has to. What about the [admittedly absurd] case of
someone at the tail of a long UUCP connection because he doesn't have
access to a real ISP yet? What about the [slightly less] absurd case of
mail out of a company that allows SMTP mail but strictly enforces some
sort of heirarchical mail server path to better track down offenders?
%
% You sound as though you've been doing this for a while, so please
% forgive the basic level of my explanations and questions,
%
% No offense taken. I try to avoid fiddling with the mail system as
% much as possible, so my knowledge of how mail transport works
% exactly is limited.
Fair enough :-)
%
% but 'b'ouncing
% hasn't changed since I met mutt at 0.88 and I can't imagine, particularly
% since it also works the same way in elm, that it was *ever* any different.
%
% Well, I belive you. What else could have changed to cause my
% troubles?
Sounds like your mail server (the easy answer, of course!).
%
% BTW, I'd like to setup my mail system to send external mails over
% a different server than internal ones (because our servers are
% blacklisted). What mailer would you recommend (exim, sendmail,
% postfix, ...?) I'm currently using exim.
I'm a qmail guy, but all of them have their fans right here on this
list. I think the topic has come up a couple of times somewhat
recently; you might check the archives for various pros and cons.
I do know that qmail is extremely {capable,small,fast,secure}, but
can also be extremely challenging to get to know.
%
% Bye
%
% Dominik ^_^ ^_^
%
% --
% Dominik Vogt, mail: [EMAIL PROTECTED], phone: 0721/91374-382
% Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe
HTH HAND
:-D
--
David T-G * It's easier to fight for one's principles
(play) [EMAIL PROTECTED] * than to live up to them. -- fortune cookie
(work) [EMAIL PROTECTED]
http://www.justpickone.org/davidtg/Shpx gur Pbzzhavpngvbaf Qrprapl Npg!
msg29651/pgp0.pgp
Description: PGP signature
Re: bouncing w/ mutt-1.3.28i
* David T-G [EMAIL PROTECTED] [2002-07-15 05:58 -0500]: % with the Message-ID: regenerated on your system, too. % % Does that mean that mutt won't be able to sort it into the correct % thread? I don't think the References: are tossed, but it's a new message and so it should get a new Message-ID: and so it changes. The MID header is left unchanged, mutt adds: Resent-From: Nicolas Rachinsky [EMAIL PROTECTED] Resent-Date: Mon, 15 Jul 2002 13:08:43 +0200 Resent-Message-ID: [EMAIL PROTECTED] Resent-To: Nicolas Rachinsky nicolas % continue to use 'bounce' since the list of Received: headers is % getting too long with this mail server. That's really odd. Your mail server should let a message go through a million hops if it has to. What about the [admittedly absurd] case of someone at the tail of a long UUCP connection because he doesn't have access to a real ISP yet? What about the [slightly less] absurd case of mail out of a company that allows SMTP mail but strictly enforces some sort of heirarchical mail server path to better track down offenders? No, not a million. I can't remeber the (default)limit at the moment, but I think it's somwhere between 15 and 200. Nicolas
Re: bouncing w/ mutt-1.3.28i
On Mon, Jul 15, 2002 at 01:12:33PM +0200, Nicolas Rachinsky wrote: * David T-G [EMAIL PROTECTED] [2002-07-15 05:58 -0500]: % with the Message-ID: regenerated on your system, too. % % Does that mean that mutt won't be able to sort it into the correct % thread? I don't think the References: are tossed, but it's a new message and so it should get a new Message-ID: and so it changes. The MID header is left unchanged, mutt adds: Resent-From: Nicolas Rachinsky [EMAIL PROTECTED] Resent-Date: Mon, 15 Jul 2002 13:08:43 +0200 Resent-Message-ID: [EMAIL PROTECTED] Resent-To: Nicolas Rachinsky nicolas Okay, if the Resent-To: header should have been added, something must have gone wrong. This are the headers of one of my bounced messages (bounced to [EMAIL PROTECTED]): snip -- Content-Type: message/rfc822 Content-Disposition: inline X-From-Line: [EMAIL PROTECTED] Tue Jul 09 22:48:30 2002 Return-path: [EMAIL PROTECTED] Envelope-to: [EMAIL PROTECTED] Delivery-date: Tue, 09 Jul 2002 22:48:30 +0400 (removed tons of Received: headers) Date: Tue, 9 Jul 2002 17:17:30 +0200 From: Dominik Vogt [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: test, please ignore Message-ID: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Resent-By: Forwarder [EMAIL PROTECTED] X-Resent-For: [EMAIL PROTECTED] X-Resent-To: [EMAIL PROTECTED], [EMAIL PROTECTED] Precedence: list X-Majordomo: 1.94.jlt7 Sender: uucp [EMAIL PROTECTED] Lines: 17 Xref: AK2614.spb.edu junk:4849 MIME-Version: 1.0 snip -- No Resent-To: header anywhere. Any good explanation for taht? Bye Dominik ^_^ ^_^ -- Dominik Vogt, mail: [EMAIL PROTECTED], phone: 0721/91374-382 Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe
Re: bouncing w/ mutt-1.3.28i
* Dominik Vogt [EMAIL PROTECTED] [2002-07-15 13:33 +0200]: On Mon, Jul 15, 2002 at 01:12:33PM +0200, Nicolas Rachinsky wrote: * David T-G [EMAIL PROTECTED] [2002-07-15 05:58 -0500]: % with the Message-ID: regenerated on your system, too. % % Does that mean that mutt won't be able to sort it into the correct % thread? I don't think the References: are tossed, but it's a new message and so it should get a new Message-ID: and so it changes. The MID header is left unchanged, mutt adds: Resent-From: Nicolas Rachinsky [EMAIL PROTECTED] Resent-Date: Mon, 15 Jul 2002 13:08:43 +0200 Resent-Message-ID: [EMAIL PROTECTED] Resent-To: Nicolas Rachinsky nicolas Okay, if the Resent-To: header should have been added, something must have gone wrong. This are the headers of one of my bounced messages (bounced to [EMAIL PROTECTED]): snip -- snip -- No Resent-To: header anywhere. Any good explanation for taht? I just tried. Either Puretec or gmx removes them. If I bounce to a local address (touching only localhost), they stay, if I bounce via puretec and GMX, they are removed. I'm sorry, but at the moment I've n time to investigate further. Nicolas
Re: bouncing w/ mutt-1.3.28i
On Mon, Jul 15, 2002 at 05:58:01AM -0500, David T-G wrote: | % continue to use 'bounce' since the list of Received: headers is | % getting too long with this mail server. | | That's really odd. Your mail server should let a message go through a | million hops if it has to. It's a crude, but effective, loop detection mechanism (mentioned in RFC 821 as well). When the MTA sees what it thinks is an excessive number of Received: headers it figures a mail loop has occured and bounces the message instead. -D -- Through love and faithfulness sin is atoned for; through the fear of the Lord a man avoids evil. Proverbs 16:6 http://dman.ddts.net/~dman/ msg29703/pgp0.pgp Description: PGP signature
Re: bouncing w/ mutt-1.3.28i
--Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Alas! Derrick 'dman' Hudson spake thus: On Mon, Jul 15, 2002 at 05:58:01AM -0500, David T-G wrote: It's a crude, but effective, loop detection mechanism (mentioned in RFC 821 as well). When the MTA sees what it thinks is an excessive number of Received: headers it figures a mail loop has occured and bounces the message instead. Wouldn't it be more effective to check the Received headers to see if it's gone through the same server twice, and /then/ bounce the mail? It's not a mail loop if it just has a lot of servers to go through. --=20 Rob 'Feztaa' Park http://members.shaw.ca/feztaa/ -- Today is the last day of your life so far. --Q68bSM7Ycu6FN28Q Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9M3RtPTh2iSBKeccRAlo6AJ4uxO4NQ6okJb2xKULPkOspAgsEkwCeOCXD 7yp0u8W1hcOFrgqtyXxxA9A= =qtH2 -END PGP SIGNATURE- --Q68bSM7Ycu6FN28Q--
Re: bouncing w/ mutt-1.3.28i
Hi, * Rob 'Feztaa' Park [02-07-16 03:34:04 +0200] wrote: Alas! Derrick 'dman' Hudson spake thus: It's a crude, but effective, loop detection mechanism (mentioned in RFC 821 as well). When the MTA sees what it thinks is an excessive number of Received: headers it figures a mail loop has occured and bounces the message instead. Wouldn't it be more effective to check the Received headers to see if it's gone through the same server twice, and /then/ bounce the mail? RfC 2821 suggests using dump counting. It's not a mail loop if it just has a lot of servers to go through. After reading a little in RfC 2821 it made me sick, escpecially section 6.2. ,[ rfc2821.txt ]- | | 6.2 Loop Detection | | Simple counting of the number of Received: headers in a | message has proven to be an effective, although rarely | optimal, method of detecting loops in mail systems. SMTP | servers using this technique SHOULD use a large rejection | threshold, normally at least 100 Received entries. Whatever | mechanisms are used, servers MUST contain provisions for | detecting and stopping trivial loops. `- (esp. ``SHOULD use a large...'', this has to read: ``MUST use at least 100...'') ...whatever the authors consider a mechanism to detect a trivial loop to be. If I had to write software detecting loops I would only check Received: headers. It needs some more than just this: virtual domains, Received: headers can be faked, etc. But by simply counting the number of hops the mail went through is not really clever allthough it's unlikely that there're 100 relays within a mail route. But the number of hops is not necessarily low, content filters (like virus scanners: 10 hops with 3 filters each make already 30 hops). bye, Rocco
Re: bouncing w/ mutt-1.3.28i
Hi, * Derrick 'dman' Hudson [02-07-14 06:02:40 +0200] wrote: On Sat, Jul 13, 2002 at 10:08:52PM -0500, David T-G wrote: | Hmmm... Perhaps I've misunderstood envelope; I thought that it was all | of the headers. No, the envelope normally isn't in the headers at all. It will only appear there if you configure your MTA to add 'Return-Path:' and 'Envelope-To:' headers. Doesn't a receiving MTA set the value of Return-Path: to the result of MAIL FROM? bye, Rocco
Re: bouncing w/ mutt-1.3.28i
On Sun, Jul 14, 2002 at 01:55:15PM +0200, Rocco Rutte wrote: | * Derrick 'dman' Hudson [02-07-14 06:02:40 +0200] wrote: | On Sat, Jul 13, 2002 at 10:08:52PM -0500, David T-G wrote: | | | Hmmm... Perhaps I've misunderstood envelope; I thought that it was all | | of the headers. | | No, the envelope normally isn't in the headers at all. It will only | appear there if you configure your MTA to add 'Return-Path:' and | 'Envelope-To:' headers. | | Doesn't a receiving MTA set the value of Return-Path: to the | result of MAIL FROM? IFF you configured it to do so. At least some MTAs don't put a Return-Path: header in by default. Also, what happens in the case of MTA1 delivering the message to [EMAIL PROTECTED], then the user uses fetchmail to re-deliver it to [EMAIL PROTECTED]? That could result in 2 Return-Path: headers ... The envelope really is separate from the rest of the message (headers+body), but some MTAs can be / are configured to store it in the headers of the message for the convenience of the final recipient. -D -- Like a gold ring in a pig's snout is a beautiful woman who shows no discretion. Proverbs 11:22 http://dman.ddts.net/~dman/ msg29634/pgp0.pgp Description: PGP signature
Re: bouncing w/ mutt-1.3.28i
* Derrick 'dman' Hudson [EMAIL PROTECTED] [2002-07-14 13:19 -0500]: On Sun, Jul 14, 2002 at 01:55:15PM +0200, Rocco Rutte wrote: | * Derrick 'dman' Hudson [02-07-14 06:02:40 +0200] wrote: | On Sat, Jul 13, 2002 at 10:08:52PM -0500, David T-G wrote: | | | Hmmm... Perhaps I've misunderstood envelope; I thought that it was all | | of the headers. | | No, the envelope normally isn't in the headers at all. It will only | appear there if you configure your MTA to add 'Return-Path:' and | 'Envelope-To:' headers. | | Doesn't a receiving MTA set the value of Return-Path: to the | result of MAIL FROM? IFF you configured it to do so. At least some MTAs don't put a Return-Path: header in by default. Also, what happens in the case of MTA1 delivering the message to [EMAIL PROTECTED], then the user uses fetchmail to re-deliver it to [EMAIL PROTECTED]? That could result in 2 Return-Path: headers ... IIRC fetchmail removes the header. Nicolas
Re: bouncing w/ mutt-1.3.28i
Derrick, et al -- ...and then Derrick 'dman' Hudson said... % % On Fri, Jul 12, 2002 at 08:38:57PM -0700, Will Yardley wrote: % | Derrick 'dman' Hudson wrote: % | On Fri, Jul 12, 2002 at 09:18:21PM -0500, David T-G wrote: % | % | When you bounce a message, mutt takes the message as it was received by % | you and hands it back to sendmail with a new addressee so that sendmail ... % | bounce message to go to you if the bounce failed, rather than to the % | sender of the original message % % I agree. Just don't be surprised when it happens because someone said % nothing is changed :-). Yeah. Good point. % % Oh, actually, the entire envelope is changed. I think David meant to % write headers -- % nothing in the message headers (or body) is changed, and new % headers are added Hmmm... Perhaps I've misunderstood envelope; I thought that it was all of the headers. Anyway, you've all done a good job of further clarifying and to my edification as well :-) % % -D HAND :-D -- David T-G * It's easier to fight for one's principles (play) [EMAIL PROTECTED] * than to live up to them. -- fortune cookie (work) [EMAIL PROTECTED] http://www.justpickone.org/davidtg/Shpx gur Pbzzhavpngvbaf Qrprapl Npg! msg29622/pgp0.pgp Description: PGP signature
Re: bouncing w/ mutt-1.3.28i
On Sat, Jul 13, 2002 at 10:08:52PM -0500, David T-G wrote: | ...and then Derrick 'dman' Hudson said... | % Oh, actually, the entire envelope is changed. I think David meant to | % write headers -- | % nothing in the message headers (or body) is changed, and new | % headers are added | | Hmmm... Perhaps I've misunderstood envelope; I thought that it was all | of the headers. No, the envelope normally isn't in the headers at all. It will only appear there if you configure your MTA to add 'Return-Path:' and 'Envelope-To:' headers. Here's an example of an SMTP session (eg one for a message bounced by mutt), but with some of the longer content remove for the sake of this mailing list. 220 ns.gbnet.net ESMTP EHLO dman.ddts.net 250-ns.gbnet.net 250-PIPELINING 250 8BITMIME MAIL FROM:[EMAIL PROTECTED] 250 ok RCPT TO:[EMAIL PROTECTED] 250 ok DATA 354 go ahead Received: (all received headers remain, but snipped in this example) Date: Sat, 13 Jul 2002 22:08:52 -0500 From: David T-G [EMAIL PROTECTED] To: Undisclosed-Recipient:; Message-ID: [EMAIL PROTECTED] Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.4i Precedence: bulk List-Unsubscribe: mailto:[EMAIL PROTECTED]?body=unsubscribe Subject: Re: bouncing w/ mutt-1.3.28i Content-Type: multipart/signed; micalg=pgp-sha1; protocol=application/pgp-signature; boundary=Ah9ph+G2cWRpKogL [body of the message] . 250 OK QUIT 221 ns.gbnet.net closing connection In this case, the envelope sender is [EMAIL PROTECTED] and the envelope recipient is [EMAIL PROTECTED]. The envelope is the data in the SMTP dialog. The headers are part of the DATA segment of the SMTP transfer. As far as SMTP is concerned, headers and body are all part of the message and are a (mostly) a black box. The envelope and the headers often correspond, but don't always (and in the case of spam, often have no relationship at all). -D -- If you hold to [Jesus'] teaching, you are really [Jesus'] disciples. Then you will know the truth, and the truth will set you free. John 8:31-32 http://dman.ddts.net/~dman/ msg29624/pgp0.pgp Description: PGP signature
Re: bouncing w/ mutt-1.3.28i
On Thu, Jul 11, 2002 at 12:17:28PM -0500, Aaron Schrab wrote: At 13:30 +0200 11 Jul 2002, Dominik Vogt [EMAIL PROTECTED] wrote: On Wed, Jul 10, 2002 at 01:54:33PM -0500, Aaron Schrab wrote: Not that I recall. It's always pretty much just resubmitted the message as is, but with new envelope recipients. Shouldn't it add a Resend-To: header? It does, along with various other Resent- headers. My main point was that the bounce command hasn't really changed, and that (for the most part) it doesn't alter the message. Hm, I have a report from someone who receives these messages that *sometimes* there is no Resent-To: header. He claims that happens about 5 times per year with my mails (he notices only when his mail filter doesn't sort the mail into the mailing list folder). Given that I bouce about three to five mails per months, this happens quite rarely. I haven't seen the headers of such a mail, though. Bye Dominik ^_^ ^_^ -- Dominik Vogt, mail: [EMAIL PROTECTED], phone: 0721/91374-382 Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe
Re: bouncing w/ mutt-1.3.28i
Dominik -- One thing I didn't see revisited was your subscription problem. Are you now subscribed? Do you want to be? Anyway, we come back to this problem of bouncing messages. When you bounce a message, mutt takes the message as it was received by you and hands it back to sendmail with a new addressee so that sendmail can put it on its way. This is just like a .forward file in that sense (though it's done manually, of course); nothing in the message envelope is changed, and new headers are added. When you resend a message, all of the transit-related headers (Received:) are thrown away, the identification headers (From:) are available to change as necessary, and the body is wrapped in a new envelope. I'm almost certain that it's completely a new message, with the Message-ID: regenerated on your system, too. All you're doing is using the old message as a template for an entirely new message that happens to look very similar (usually). What is it that you used to do, and what is it that you really want to do? You sound as though you've been doing this for a while, so please forgive the basic level of my explanations and questions, but 'b'ouncing hasn't changed since I met mutt at 0.88 and I can't imagine, particularly since it also works the same way in elm, that it was *ever* any different. Just some thoughts... :-D -- David T-G * It's easier to fight for one's principles (play) [EMAIL PROTECTED] * than to live up to them. -- fortune cookie (work) [EMAIL PROTECTED] http://www.justpickone.org/davidtg/Shpx gur Pbzzhavpngvbaf Qrprapl Npg! msg29592/pgp0.pgp Description: PGP signature
Re: bouncing w/ mutt-1.3.28i
On Wed, Jul 10, 2002 at 01:54:33PM -0500, Aaron Schrab wrote: Hrm. That sounded like a good explanation. Was there any change in the bounce function? Not that I recall. It's always pretty much just resubmitted the message as is, but with new envelope recipients. Shouldn't it add a Resend-To: header? Bye Dominik ^_^ ^_^ -- Dominik Vogt, mail: [EMAIL PROTECTED], phone: 0721/91374-382 Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe
Re: bouncing w/ mutt-1.3.28i
At 13:30 +0200 11 Jul 2002, Dominik Vogt [EMAIL PROTECTED] wrote: On Wed, Jul 10, 2002 at 01:54:33PM -0500, Aaron Schrab wrote: Not that I recall. It's always pretty much just resubmitted the message as is, but with new envelope recipients. Shouldn't it add a Resend-To: header? It does, along with various other Resent- headers. My main point was that the bounce command hasn't really changed, and that (for the most part) it doesn't alter the message. The addition of a few headers is outside the scope of what I was commenting on. -- Aaron Schrab [EMAIL PROTECTED] http://www.schrab.com/aaron/ If you consistently take an antagonistic approach, however, people are going to start thinking you're from New York. :-) --Larry Wall to Dan Bernstein
bouncing w/ mutt-1.3.28i
Problem: With said mutt release I can't bounce messages anymore. (I found another question in the newsgroup w/ 1.3.23, but no solution to the problem). Actually, the message *is* bounced, but unlike earlier releases, it leaves both, the From: and Cc: headers untouched. So, if I bounce a mail that was originally sent from sender A to me to a list B, the mail still looks as if A sent it to me, not A to B. Of course the spam filters on the mailing list don't like that a bit and unceremonously reject the bounce mail :P How do I get bouncing to work again (preferrably without installing an older mutt version)? Bye Dominik ^_^ ^_^ P.S.: Please CC me, I'm not subscribed to the mailing list (and all my previous attempts to subscribe failed). -- Dominik Vogt, mail: [EMAIL PROTECTED], phone: 0721/91374-382 Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe
Re: bouncing w/ mutt-1.3.28i
At 17:19 +0200 10 Jul 2002, Dominik Vogt [EMAIL PROTECTED] wrote: Problem: With said mutt release I can't bounce messages anymore. Actually, the message *is* bounced, but unlike earlier releases, it leaves both, the From: and Cc: headers untouched. So, if I That's how it's always worked, at least for as long as I've been using mutt (since somewhere around 0.42). Check out the resend-message command (bound to Esce by default). But that's not the only problem you're having with spam filters. One of the mail servers handling your outgoing mail appears to have gotten itself blacklisted: SPAM: Start SpamAssassin results -- SPAM: This mail is probably spam. The original message has been altered SPAM: so you can recognise or block similar unwanted mail in future. SPAM: See http://spamassassin.org/tag/ for more details. SPAM: SPAM: Content analysis details: (5 hits, 5 required) SPAM: Hit! (2.0 points) Received via a relay in relays.osirusoft.com SPAM:[RBL check: found 148.224.20.195.relays.osirusoft.com., type: 127.0.0.4] SPAM: Hit! (3.0 points) DNSBL: sender is Confirmed Spam Source SPAM: SPAM: End of SpamAssassin results - See http://relays.osirusoft.com/cgi-bin/rbcheck.cgi?addr=195.20.224.148 -- Aaron Schrab [EMAIL PROTECTED] http://www.schrab.com/aaron/ [Samba] enables open-source fans to stealth their Linux boxes so they look like Microsoft servers that somehow miraculously fail to suck. -- Eric S. Raymond
Re: bouncing w/ mutt-1.3.28i
On Wed, Jul 10, 2002 at 11:19:45AM -0500, Aaron Schrab wrote: At 17:19 +0200 10 Jul 2002, Dominik Vogt [EMAIL PROTECTED] wrote: Problem: With said mutt release I can't bounce messages anymore. Actually, the message *is* bounced, but unlike earlier releases, it leaves both, the From: and Cc: headers untouched. So, if I ^ To: of course That's how it's always worked, at least for as long as I've been using mutt (since somewhere around 0.42). Check out the resend-message command (bound to Esce by default). That's what the admin of the mailing list told me. There must be a difference since he did not need to approve bounced messages manually before. Hrm. That sounded like a good explanation. Was there any change in the bounce function? One other thing: the admin mentioned that after bouncing, the list of Received: headers has gotten too long - another reason why the mail is rejected. Can I do something about this in mutt? Or exim? But that's not the only problem you're having with spam filters. One of the mail servers handling your outgoing mail appears to have gotten itself blacklisted: Yes, I'm aware of this problem. As an employee of the company hosting these mail servers I'd better not make any comments about this. :-) Bye Dominik ^_^ ^_^ -- Dominik Vogt, mail: [EMAIL PROTECTED], phone: 0721/91374-382 Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe
