|
|
|
|
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.txthttp://mail.triad.ath.cx/postfinger-06122008.txthttp://mail.triad.ath.cx/saslfinger-06122008.txtany 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 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.
|
|
|
> [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
|
|
|
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.htmlIf you need more help rejecting unknown recipients, start a
new thread on that subject.
http://www.postfix.org/DEBUG_README.html#mailIt'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
|
|
|
> [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
|
|
|
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 __
((__)(('(( ((_)
|
|
Locked
