Is there any way to use relocated_maps to cause a soft bounce for some
addresses and hard bounce for others? Or is there a better way to do this? Thanks! -- Josh Miller, RHCE |
[hidden email]:
> Is there any way to use relocated_maps to cause a soft bounce for some > addresses and hard bounce for others? The user would receive the bounce message a few days later, when th email expires in the queue. > Or is there a better way to do this? What problem are you trying to solve? Please describe the problem, instead of the (soft bounce) solution. Wietse |
okay, i'm having difficulties again. we've now upgraded from SuSE 9.1 to
SuSE 9.2 and are experiencing some... problems. initially we wanted to go to SuSE 9.3, but there are a LOT of broken dependencies and incorrect packages between them, and it's even worse with 10.x, so 9.2 it is. i'm looking into upgrading to 10.x sometime down the road, but it doesn't look promising. anyway, there are some issues. something has broken in amavisd-new and clamav, it's marking every incoming mail as virus and quarantining them all. NOTHING is getting through. i disabled spam and av in amavisd, so it's passing messages properly again, but nothing is being checked, and i don't like that. i'd really like to know what changed and how to fix it. the system also has avguard installed, i don't know if that could be part of the problem or not. there were some other issues, such as saslauthd wasn't being started so smtp-auth was failing, and a broken permission in one of the config files. oh, and some important perl modules had to be re-installed for amavisd-new to work at all. i'm seeing a lot of "popper[8857]: (v4.0.5) Unable to get canonical name of client x.x.x.x: Unknown host (1)" in the logs. i'm sure there are many other things that are going to have to be sorted out, but for the moment it appears to be mostly working. one thing at a time. right now, i'm trying to sort out a relay issue. when i tested it for open relay, it passed most tests with the exception of one: RSET 250 Ok MAIL FROM: [hidden email] 250 Ok RCPT TO: [hidden email] Test Failed, 250 Ok now how do i fix this? i'm reasonably certain this wasn't a problem before, but now it is. i also think tls/sasl aren't working properly, but i'm not positive. they *seem* to be working, i think. i want the server to refuse unauthenticated sending attempts. right now, i can disable smtp auth in a mail client, and it'll send through the server. at first with smtp auth enabled in the clients, it would refuse to authenticate. i've fixed it so that smtp-auth appears to work properly, now i'd like to force smtp-auth only if possible. i know this really isn't the right list for these, but if anyone has any suggestions for how to deal with av and amavisd-new, i'd really like to hear it. or directions on where to go to ask the right forum/list. any hints on the canonical name problem would also be most helpful. there were some other things, such as the broken permission i noted earlier. but in researching before asking, i found a few earlier posts that helped track down and solve that particular problem, and a couple other things as well. i've looked around quite a bit before asking for help, trying to solve it myself. i'm just not sure how to proceed from here without some pointers. postconf, saslfinger, postfinger should be available at: http://mail.triad.ath.cx/postconf-06122008.txt http://mail.triad.ath.cx/postfinger-06122008.txt http://mail.triad.ath.cx/saslfinger-06122008.txt any and all suggestions, observations, comments welcome. up to a few days ago, the machine was working exactly as intended, with no major issues of note. i'd like to return to that happy condition as soon as possible, if possible. all help is greatly appreciated. --Mac |
On Thu, Jun 12, 2008 at 07:37:45PM -0700, Postfix Support Mail wrote:
> okay, i'm having difficulties again. we've now upgraded from SuSE 9.1 to > SuSE 9.2 and are experiencing some... problems. initially we wanted to go > to SuSE 9.3, but there are a LOT of broken dependencies and incorrect > packages between them, and it's even worse with 10.x, so 9.2 it is. i'm > looking into upgrading to 10.x sometime down the road, but it doesn't look > promising. Piece of advice that is too late: Don't do major O/S upgrades on production systems in place, build a new system and migrate. Perform a backup if you decide to upgrade anyway, and if it backfires, go back. > any and all suggestions, observations, comments welcome. up to a few days > ago, the machine was working exactly as intended, with no major issues of > note. i'd like to return to that happy condition as soon as possible, if > possible. all help is greatly appreciated. Your system is too far gone. Build a replacement. Do not attempt to fix a system in an unknown severely broken state. I don't hear a Postfix problem here, just a totally messed up O/S. You need a sysadmin help list, not a Postfix list. -- Viktor. Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the "Reply-To" header. To unsubscribe from the postfix-users list, visit http://www.postfix.org/lists.html or click the link below: <mailto:[hidden email]?body=unsubscribe%20postfix-users> If my response solves your problem, the best way to thank me is to not send an "it worked, thanks" follow-up. If you must respond, please put "It worked, thanks" in the "Subject" so I can delete these quickly. |
In reply to this post by Postfix Support Mail
Postfix Support Mail wrote:
> okay, i'm having difficulties again. we've now upgraded from SuSE 9.1 to > SuSE 9.2 and are experiencing some... problems. initially we wanted to go > to SuSE 9.3, but there are a LOT of broken dependencies and incorrect > packages between them, and it's even worse with 10.x, so 9.2 it is. i'm > looking into upgrading to 10.x sometime down the road, but it doesn't look > promising. Well, suse 9.2 is out of support AFAIK - or did you by chance actually mean sles 9 sp2? In any case, I'm running postfix, spamassassin, clamav, razor et al on a number of suse linux versions - sles 9, sles 10, opensuse 10.3 - and everything is working well, so I don't think the distro is the problem. > > anyway, there are some issues. something has broken in amavisd-new and > clamav, it's marking every incoming mail as virus and quarantining them all. > NOTHING is getting through. i disabled spam and av in amavisd, so it's > passing messages properly again, but nothing is being checked, and i don't > like that. i'd really like to know what changed and how to fix it. the > system also has avguard installed, i don't know if that could be part of the > problem or not. What changed? > there were some other issues, such as saslauthd wasn't being started so > smtp-auth was failing, and a broken permission in one of the config files. > oh, and some important perl modules had to be re-installed for amavisd-new > to work at all. i'm seeing a lot of "popper[8857]: (v4.0.5) Unable to get > canonical name of client x.x.x.x: Unknown host (1)" in the logs. i'm sure > there are many other things that are going to have to be sorted out, but for > the moment it appears to be mostly working. one thing at a time. This sounds like a bit of a disaster - how many other people have root access, and could they have mucked something up? > right now, i'm trying to sort out a relay issue. when i tested it for open > relay, it passed most tests with the exception of one: > > RSET > 250 Ok > MAIL FROM: [hidden email] > 250 Ok > RCPT TO: [hidden email] > Test Failed, 250 Ok > > now how do i fix this? i'm reasonably certain this wasn't a problem before, > but now it is. > > i also think tls/sasl aren't working properly, but i'm not positive. they > *seem* to be working, i think. i want the server to refuse unauthenticated > sending attempts. right now, i can disable smtp auth in a mail client, and > it'll send through the server. at first with smtp auth enabled in the > clients, it would refuse to authenticate. i've fixed it so that smtp-auth > appears to work properly, now i'd like to force smtp-auth only if possible. Yikes, this is a disaster - time to restore from backup and get back to a known good configuration. The postfix symptoms are just the tip of the iceberg, IMHO. Joe |
## >> Well, suse 9.2 is out of support AFAIK - or did you by
## >> chance actually mean sles 9 sp2? while i have both SLES9 and SLES10 in my software library, neither is installed on the machine in question. it's SuSE 9.2 Professional, upgraded from 9.1 professional. this server was built before SLES9 was released, quite a long time ago. yes 9.2 is out of support, i'm allright with that for the moment. up to now the server's been working correctly and mostly trouble-free, i saw no reason to change it. if i can get it fixed up again, i still see no reason to change the version. i like 9.x a lot, and for my application, it's pretty much ideal. ## >> In any case, I'm running postfix, spamassassin, clamav, ## >> razor et al on a number of suse linux versions - sles 9, ## >> sles 10, opensuse 10.3 - and everything is working well, ## >> so I don't think the distro is the problem. i'm certain the distribution isn't the problem. everything was working properly before, and i've built nearly identical systems based on SuSE 9.x, 10.x, SLES9 and SLES10 for clients in recent past with no major issues. up to now, this particular system was working fine. ## >> What changed? ahhh, what changed. what changed indeed. this whole problem began a few days ago when the server cooked its CPU and burned both NICs. the whole machine stopped responding to remote connections, couldn't SSH in, didn't respond to SMTP, POP, IMAP, HTTP, nothing. i tried to log into the console and again, nothing. the machine had locked up. no choice but to reset... at which time it would not reboot. replaced the CPU and both NICs, up the machine came... in a damaged state that would not boot. booting to a rescue disc showed a damaged filesystem, /dev compleatly hosed, but no other obvious damage. i am reasonably convinced that most of my current problems are due to the changes that the update to 9.2 made in the configuration. but, i am not 100% positive, nor am i sure how best to proceed in addressing these issues, hence the questions to this list. ## >> This sounds like a bit of a disaster - how many other ## >> people have root access, and could they have mucked something up? two people have root access, two others have sudo access. so far as i can tell, none of the people who have access to the machine mucked anything up, and from what i can tell from the salvaged filesystem, it doesn't appear that an outsider or intruder did anything either, though it's entirely possible that any trace was lost during recovery. i was more concerned with getting the machine back online than i was with potential forensics. i just assumed that the damage was related to the CPU/NIC problems. it didn't occur to me till later that it could have been something else, but i suppose it's possible. as near as i can figure out, the CPU cooked off during some kind of critical operation with the filesystem. i'm not entirely positive of that, but that is how it appears. i have no other explanation for why the entire contents of /dev was gone upon boot and i didn't find any other obvious problems when i examined the system with a rescue disc. i replaced the hard drive as well as both NICs and the CPU, just in case. ## >> Yikes, this is a disaster - time to restore from backup ## >> and get back to a known good configuration. The postfix ## >> symptoms are just the tip of the iceberg, IMHO. and this is the crux of the problem. i don't have a valid backup available. i won't go into details, but let's just say it's due in part to things disappearing after a major move, and not having taken a backup since a little before the move. i know, i know, go ahead and shoot me now. any suggestions as to how best to proceed under the circumstances? thanks for the input --Mac |
In reply to this post by Josh Miller
* [hidden email] <[hidden email]>:
> Is there any way to use relocated_maps to cause a soft bounce for some > addresses and hard bounce for others? What would be the point of this? -- Ralf Hildebrandt ([hidden email]) [hidden email] Postfix - Einrichtung, Betrieb und Wartung Tel. +49 (0)30-450 570-155 http://www.arschkrebs.de A: No. Q: Should I include quotations after my reply? |
In reply to this post by Postfix Support Mail
Postfix Support Mail wrote:
> ## >> Well, suse 9.2 is out of support AFAIK - or did you by > ## >> chance actually mean sles 9 sp2? > > while i have both SLES9 and SLES10 in my software library, neither is > installed on the machine in question. it's SuSE 9.2 Professional, upgraded > from 9.1 professional. this server was built before SLES9 was released, > quite a long time ago. > > yes 9.2 is out of support, i'm allright with that for the moment. up to now > the server's been working correctly and mostly trouble-free, i saw no reason > to change it. if i can get it fixed up again, i still see no reason to > change the version. i like 9.x a lot, and for my application, it's pretty > much ideal. > > ## >> In any case, I'm running postfix, spamassassin, clamav, > ## >> razor et al on a number of suse linux versions - sles 9, > ## >> sles 10, opensuse 10.3 - and everything is working well, > ## >> so I don't think the distro is the problem. > > i'm certain the distribution isn't the problem. everything was working > properly before, and i've built nearly identical systems based on SuSE 9.x, > 10.x, SLES9 and SLES10 for clients in recent past with no major issues. up > to now, this particular system was working fine. > > ## >> What changed? > > ahhh, what changed. what changed indeed. this whole problem began a few > days ago when the server cooked its CPU and burned both NICs. the whole > machine stopped responding to remote connections, couldn't SSH in, didn't > respond to SMTP, POP, IMAP, HTTP, nothing. i tried to log into the console > and again, nothing. the machine had locked up. no choice but to reset... > at which time it would not reboot. replaced the CPU and both NICs, up the > machine came... in a damaged state that would not boot. booting to a > rescue disc showed a damaged filesystem, /dev compleatly hosed, but no other > obvious damage. i am reasonably convinced that most of my current problems > are due to the changes that the update to 9.2 made in the configuration. > but, i am not 100% positive, nor am i sure how best to proceed in addressing > these issues, hence the questions to this list. > > ## >> This sounds like a bit of a disaster - how many other > ## >> people have root access, and could they have mucked something up? > > two people have root access, two others have sudo access. so far as i can > tell, none of the people who have access to the machine mucked anything up, > and from what i can tell from the salvaged filesystem, it doesn't appear > that an outsider or intruder did anything either, though it's entirely > possible that any trace was lost during recovery. i was more concerned with > getting the machine back online than i was with potential forensics. i just > assumed that the damage was related to the CPU/NIC problems. it didn't > occur to me till later that it could have been something else, but i suppose > it's possible. > > as near as i can figure out, the CPU cooked off during some kind of critical > operation with the filesystem. i'm not entirely positive of that, but that > is how it appears. i have no other explanation for why the entire contents > of /dev was gone upon boot and i didn't find any other obvious problems when > i examined the system with a rescue disc. i replaced the hard drive as well > as both NICs and the CPU, just in case. > > ## >> Yikes, this is a disaster - time to restore from backup > ## >> and get back to a known good configuration. The postfix > ## >> symptoms are just the tip of the iceberg, IMHO. > > and this is the crux of the problem. i don't have a valid backup available. > i won't go into details, but let's just say it's due in part to things > disappearing after a major move, and not having taken a backup since a > little before the move. i know, i know, go ahead and shoot me now. > > any suggestions as to how best to proceed under the circumstances? > backup your data if not already done, then reinstall the machine. this will be faster and you will not have to deal with a mixed distribution on your system. |
In reply to this post by Postfix Support Mail
Postfix Support Mail wrote, at 06/12/2008 10:37 PM:
> right now, i'm trying to sort out a relay issue. when i tested it for open > relay, it passed most tests with the exception of one: > > RSET > 250 Ok > MAIL FROM: [hidden email] > 250 Ok > RCPT TO: [hidden email] > Test Failed, 250 Ok That's not an open relay test if mail.triad.ath.cx is in $mydestination. Being an open relay means that others can use your server freely to relay to unauthorized destinations. |
In reply to this post by Wietse Venema
> [hidden email]:
>> Is there any way to use relocated_maps to cause a soft bounce for some >> addresses and hard bounce for others? > > The user would receive the bounce message a few days later, > when th email expires in the queue. > >> Or is there a better way to do this? > > What problem are you trying to solve? Please describe the problem, > instead of the (soft bounce) solution. I'm setting up a test environment and trying to solve two test case scenarios, one is soft bounce, the other is hard bounce. I suppose I could simply setup two postfix instances and have one set to soft bounce with the other set to hard bounce. Thanks, -- Josh Miller, RHCE |
[hidden email]:
> > [hidden email]: > >> Is there any way to use relocated_maps to cause a soft bounce for some > >> addresses and hard bounce for others? > > > > The user would receive the bounce message a few days later, > > when th email expires in the queue. > > > >> Or is there a better way to do this? > > > > What problem are you trying to solve? Please describe the problem, > > instead of the (soft bounce) solution. > > I'm setting up a test environment and trying to solve two test case > scenarios, one is soft bounce, the other is hard bounce. Can you describe the problem instead of the (hard/soft bounce) solution. Wietse |
In reply to this post by Jorey Bump
Jorey Bump wrote:
> Postfix Support Mail wrote, at 06/12/2008 10:37 PM: > >> right now, i'm trying to sort out a relay issue. when i tested it for >> open >> relay, it passed most tests with the exception of one: >> >> RSET >> 250 Ok >> MAIL FROM: [hidden email] >> 250 Ok >> RCPT TO: [hidden email] >> Test Failed, 250 Ok > > That's not an open relay test if mail.triad.ath.cx is in $mydestination. > Being an open relay means that others can use your server freely to > relay to unauthorized destinations. > This appears to be checking if you will accept mail sent from and directed to non-existent local users. In particular, accepting mail addressed to non-existent recipients will cause a bounce, creating backscatter. If you generate a lot of backscatter, you will eventually be blacklisted. Make sure your system rejects mail addressed to non-existent recipients. Here's a starting place: http://www.postfix.org/LOCAL_RECIPIENT_README.html If you need more help rejecting unknown recipients, start a new thread on that subject. http://www.postfix.org/DEBUG_README.html#mail It's probably a good idea to reject mail FROM local users that don't exist, but this is more of a local anti-UCE policy issue than a security issue. http://www.postfix.org/postconf.5.html#smtpd_reject_unlisted_sender -- Noel Jones |
In reply to this post by Wietse Venema
> [hidden email]:
>> > [hidden email]: >> >> Is there any way to use relocated_maps to cause a soft bounce for >> some >> >> addresses and hard bounce for others? >> > >> > The user would receive the bounce message a few days later, >> > when th email expires in the queue. >> > >> >> Or is there a better way to do this? >> > >> > What problem are you trying to solve? Please describe the problem, >> > instead of the (soft bounce) solution. >> >> I'm setting up a test environment and trying to solve two test case >> scenarios, one is soft bounce, the other is hard bounce. > > Can you describe the problem instead of the (hard/soft bounce) solution. I am designing a new environment to test an application where we can test the application's response to various email scenarios. The scenarios should include success, hard bounce, and soft bounce from the mail server which would dictate whether or not the DB gets updated with an invalid email flag or not. If it's a hard bounce, the record should get an invalid email flag, soft bounce would indicate temporarily unavailable, etc... Thanks! -- Josh Miller, RHCE |
Josh Miller wrote:
>> [hidden email]: >>>> [hidden email]: >>>>> Is there any way to use relocated_maps to cause a soft bounce for >>> some >>>>> addresses and hard bounce for others? >>>> The user would receive the bounce message a few days later, >>>> when th email expires in the queue. >>>> >>>>> Or is there a better way to do this? >>>> What problem are you trying to solve? Please describe the problem, >>>> instead of the (soft bounce) solution. >>> I'm setting up a test environment and trying to solve two test case >>> scenarios, one is soft bounce, the other is hard bounce. >> Can you describe the problem instead of the (hard/soft bounce) solution. > > I am designing a new environment to test an application where we can test > the application's response to various email scenarios. The scenarios > should include success, hard bounce, and soft bounce from the mail server > which would dictate whether or not the DB gets updated with an invalid > email flag or not. If it's a hard bounce, the record should get an > invalid email flag, soft bounce would indicate temporarily unavailable, > etc... > > Thanks! > -- > Josh Miller, RHCE > Use the smtp-sink test program included with postfix source code. It can be configured accept or reject mail, or fail in various ways to test your sending app. http://www.postfix.org/smtp-sink.1.html -- Noel Jones |
In reply to this post by mouss-2
mouss wrote:
> backup your data if not already done, then reinstall the machine. this > will be faster and you will not have to deal with a mixed distribution > on your system. I'd have to agree, from experience, that would be the shortest path back to sanity - assuming you're still working with fully sane hardware... Joe |
On Fri, Jun 13, 2008 at 10:32 PM, Joe Sloan <[hidden email]> wrote:
> mouss wrote: > >> backup your data if not already done, then reinstall the machine. this >> will be faster and you will not have to deal with a mixed distribution on >> your system. > > I'd have to agree, from experience, that would be the shortest path back to > sanity - assuming you're still working with fully sane hardware... > > Joe > yeah, i agree too... reinstall should be the easiest way to fix your problems -- Roberto Scattini ___ _ ))_) __ )L __ ((__)(('(( ((_) |
Free forum by Nabble | Edit this page |