bouncing emails from temp. domain
Hello, I have a lunux setup and a temporary dialup connection. Sometimes when I try to send somebody email it gets bounced with the following complaint: - Transcript of session follows - ... while talking to mx0.gmx.de.: >>> MAIL From:<[EMAIL PROTECTED]> BODY=8BITMIME <<< 550 Cannot resolve your domain - ungueltiger Domain-Name in Adresse 554 [EMAIL PROTECTED] Service unavailable --UAA00925.959908551/werich.enteract.com Content-Type: message/delivery-status Reporting-MTA: dns; werich.enteract.com Arrival-Date: Thu, 1 Jun 2000 20:15:49 -0500 Final-Recipient: RFC822; [EMAIL PROTECTED] Action: failed Status: 5.0.0 Remote-MTA: DNS; mx0.gmx.de Diagnostic-Code: SMTP; 550 Cannot resolve your domain - ungueltiger Domain-Name i n Adresse Last-Attempt-Date: Thu, 1 Jun 2000 20:15:51 -0500 --UAA00925.959908551/werich.enteract.com Content-Type: message/rfc822 Content-Transfer-Encoding: 8bit Return-Path: Received: (from gibby@localhost) by werich.enteract.com (8.9.3/8.9.3) id UAA00923 for [EMAIL PROTECTED]; Thu, 1 Jun 2000 20:15:49 -0500 Date: Thu, 1 Jun 2000 20:15:49 -0500 From: Andrew Eichmann <[EMAIL PROTECTED]> To: =?iso-8859-1?Q?Max_K=FCnemann?= <[EMAIL PROTECTED]> Subject: Re: device busy / ZIP-drive Message-ID: <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] References: <[EMAIL PROTECTED]> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Now, it appears that it's complaining that DNS can't find werich.enteract.com, which is my linux box's domain name. I have the following in my muttrc: my_hdr Reply-to: [EMAIL PROTECTED] set hidden_host set hostname="enteract.com" I used to run pine, and didn't have this problem after I forced the header to say [EMAIL PROTECTED] Sorry if this has been covered; I searched the archives for ``bounce''... Thanks, Andy
[sureshr@staff.juno.com: Re: How do I make pop support do polling?]
Timothy Ball proclaimed on mutt-users that: >Fetchmail is frowned upon because of the fact that fetchamil basically >runs as a deamon. What's wrong with that? Andy Eichmann
Re: Re:
Hello, When I thread mailing list messages, often the thread will be broken up because of differing versions and placement of ``Re:'' in the subject line, compounded by different mail clients' handling of the subject line. For example, if the original message's Subject: line is ``[BOB] What's the frequency, Kenneth?''where ``[BOB]'' is the mailing list name that gets prepended to the subject, the replies will wind up like: ``Re: [BOB] What's the frequency, Kenneth?'' ``re: [BOB] What's the frequency, Kenneth?'' ``Re: [BOB] re: What's the frequency, Kenneth?'' ``RE: [BOB] What's the frequency, Kenneth?'' ``Re: re: [BOB] What's the frequency, Kenneth?'' usw. I searched on ``Re:'' and ``Subject:'' in the manual and didn't find anything useful looking. Is there a built-in solution to this? Does anybody else have this problem? I imagine something stripping out all variations of ``Re:'' before the threads are arranged in the list. This would be child's play in Perl, the world is not Perl. :-) Or should I start putting together a patch, right after I relearn C? Thanks, Andy Eichmann
Re: Re: Re:
On Sat, Jun 17, 2000 at 09:58:44PM -0400, David T-G wrote: > Andrew -- > > I don't have an easy answer for your question, though procmail springs to > mind for starters. You mentioned searching the manual; did you find > $reply_regexp and see what you can do with it? It's pretty fancy... Here's what I've tried so far: # set reply_regexp="^(re([\[0-9\]+])*):[\t]*" # set reply_regexp="^(re:)+[\t]*" set reply_regexp="^(\[BOB\] )?(re: )+(\[BOB\] )?(re: )*" ...and that doesn't seem to solve the problem. One weird this is that the default listed in the manual doesn't appear to adhere to the specification for regexps in the manual. > > > :-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.bigfoot.com/~davidtg/Shpx gur Pbzzhavpngvbaf Qrprapl Npg! > The "new millennium" starts at the beginning of 2001. There was no year 0. > Note: If bigfoot.com gives you fits, try sector13.org in its place. *sigh* >
Re: Re: Re:
On Sat, Jun 17, 2000 at 09:59:30PM -0500, David Champion wrote:
> I warn you now - this is more than you asked for.
Yep, it is. ;-)
Thanks anyway.
>
> On 2000.06.17, in <[EMAIL PROTECTED]>,
> "Andrew Eichmann" <[EMAIL PROTECTED]> wrote:
> > the subject line. For example, if the original message's Subject:
> > line is ``[BOB] What's the frequency, Kenneth?''where ``[BOB]'' is
> > the mailing list name that gets prepended to the subject, the replies
> > ...
> > Is there a built-in solution to this? Does anybody else have this
> > problem? I imagine something stripping out all variations of ``Re:''
>
> I have this problem, too -- it's one of the reasons I can't stand lists
> that alter your postings' subject: lines.
>
> My .procmailrc loads a file named "classaction". This file sets some
> operational defaults, then loads a bunch of matching rules from another
> file called "classes". It then alters messages as documented in
> "classaction".
>
> "classaction" and a stripped-down copy of "classes" are attached. In
> reality, I process about 120 different lists and other categories of
> like mail from this setup. It's fast, but that doesn't actually matter
> since it's asynch with my mail-reading.
>
> "$ ${XFROM}" is a procmail macro I use for matching sender addresses.
> You can substitute the built-in "^FROM" (or whatever).
>
>
> You'll note that this setup only marks messages by removing [LISTNAME]
> stuff from the subject (if STRIPLAB is set in the list's config), and
> adds the X-Label: header. I have mutt set up to do all its list
> matching on "~y listname" instead of duplicating all the patterns, so
> procmail and mutt are VERY intertwined here.
>
> (X-Label: and "~y" are a 1.3.x thing. This makes it easy to move a
> message from one category to another in Mutt's eyes. Once a message is
> archived and delivered, it's all about Mutt, and I don't worry about
> saving anything that has an X-Label: because I know it's already
> archived.)
>
> Anyway, maybe you don't want all that, but it shows how I'm using
> procmail to match the expressions. :)
>
> --
> -D. [EMAIL PROTECTED]NSITUniversity of Chicago
> ###
> ###
> ### Handle all mail classes properly, phase 1.
> ###
> ### These DEFAULTS hinge archival, labelling, and inbox display on whether
> ### ${CLASS} is defined. For these options, you need only define ${CLASS}
> ### to a shorthand for the mail class a message should belong to.
> ###
>
> ### Nullify the class name. If CLASS is undefined, mail will pass through
> ### the class-action package untouched and unarchived. (Auto-forwarding
> ### will still occur, though.) ${CLASS} implies a few things:
> ### 1. Name of the archival folder
> ### 2. Name for class labelling (X-Label header field or Subject: rewrite)
> ### If ${CLASS} is literally "null", mail in a given class will be killed off
> ### after matching.
> CLASS=
>
> ### If ${CLASS} is set to someting besides "null", and ${ARCHIVE} is set,
> ### messages will be archived. If ${ARCHIVE} is "yes", the archival folder's
> ### name will be copied from ${CLASS}. If ${ARCHIVE} is anything else, mail
> ### will be archived to that folder name.
> ###
> ### The archived copy will be unadulterated.
> ARCHIVE=yes
>
> ### If ${CLASS} is set to someting besides "null", and ${LABEL} is set,
> ### messages will have an "X-Label:" header field inserted. If ${LABEL}
> ### is "yes", the X-Label will be set to ${CLASS}. If ${LABEL} is set
> ### to any other value, the X-Label will be set to that value.
> LABEL=yes
>
> ### If ${HARDLABEL} is "yes", rewrite
> ### Subject: Re: foo
> ### as
> ### Subject: [$LABEL] Re: foo
> ### instead of inserting an X-Label: header.
> HARDLABEL=no
>
> ### If ${STRIPLAB} is set to "yes", remove anything enclosed in square
> ### brackets from the beginning, or following a leading "Re: ", of the
> ### Subject: header. If ${STRIPLAB} is set to anything else, remove
> ### only such tags if they match ${STRIPLAB}. This is for removing
> ### the tags generated by some mailing-list managers so that we can
> ### prefer X-Label:s.
> STRIPLAB=
>
> ### If ${HIDE} is set to "yes", the class-action package will not
> ### store messages in a class to the default folder (inbox). If ${HID
Re: Re: Re:
On Sat, Jun 17, 2000 at 11:54:18PM -0700, Eugene Lee wrote: > > Threads are usually broken because someone's mailer doeesn't generate > any useful trackable header like Message-ID, References, or In-Reply-To. > I would rather get the person to use a better client, or smack her/his > ISP to add this support to their mail system. > Well, hell being other people and all, I figure there should be a technical solution. I'm investigating the reply_regexp variable > As for threading by subject, it'd be nice to do what you suggested. But > this is an open-source world where code speaks volumes. So writing and > submitting a patch would be better. :) >
Re: [Fwd: help]
On Sat, Nov 17, 2001 at 07:57:04AM -0500, Bela Bartok wrote: > > I just dont want to use sendmail, if i am sending a big email, and i > disconnect, it will stay in sendmail queue, and i dont want that. I want > to the simpler, bert solution for desktop freebsd machine for handling > emails. > thanks again. > To flush out the mail queues and send things on their way, try: sendmail -q before you disconnect. Works for me. Any reason not to do it this way, folks? Regards, Andy Eichmann > >
