Debian Testing/Wheezy, kernel 2.6.38, Postfix
I've had a procmail receipe in place for a few weeks now and it's been working well.
:0 * ^(TO|FROM):.+@mydomainname.* { :0c # Send a copy to the other email account. ! someone@anotherdomainname.com # File the original as normal :0 foldername }
Then a few days ago, probably after some OS updates, it fails with:
status=deferred (host mail.*******.*****.com[000.00.00.0] said: 451 4.4.0 DNS temporary failure (chkuser) (in reply to MAIL FROM command))
(I've removed the data identifying the destination)
I have also tried sending an email directly using /usr/bin/sendmail and that produces the same result, whatever the emails destination, so I'm assuming it must be my setup. I can't explain why it worked before but doesn't now though.
I have really no idea what this means as Postfix configuration is a series of magical incantaitions which I don't understand.
Some help would be much appreciated.
On 02 Jun 12:06, Barry Samuels wrote:
Debian Testing/Wheezy, kernel 2.6.38, Postfix
I've had a procmail receipe in place for a few weeks now and it's been working well.
:0
- ^(TO|FROM):.+@mydomainname.*
{ :0c # Send a copy to the other email account. ! someone@anotherdomainname.com # File the original as normal :0 foldername }
OK... so that's about as informative as a melted chocolate tea pot that's got dog hair in it.
Then a few days ago, probably after some OS updates, it fails with:
status=deferred (host mail.*******.*****.com[000.00.00.0] said: 451 4.4.0 DNS temporary failure (chkuser) (in reply to MAIL FROM command))
(I've removed the data identifying the destination)
Yeah - I noticed - it's Really Not Useful if you're expecting sensible replies - yes, I know this is a public mailing list and is archived, but the bits that you've removed are exactly the bits we'd need to work out what's going on.
I have also tried sending an email directly using /usr/bin/sendmail and that produces the same result, whatever the emails destination, so I'm assuming it must be my setup. I can't explain why it worked before but doesn't now though.
I have really no idea what this means as Postfix configuration is a series of magical incantaitions which I don't understand.
Some help would be much appreciated.
Why do you think it's you that's broken? Are you using a smarthost? is the smart host the host that you've (convieniently... aka annoyingly so that no one can check anything for you...) edited out your own machine or somewhere else? Is it for the copy to someone@anotherdomainname.com?
If it's for the copy, then I'd suggest that the domains MX server is having issues doing DNS lookups. As it says on the tin...
On 02/06/11 13:43:31, Brett Parker wrote:
On 02 Jun 12:06, Barry Samuels wrote:
Debian Testing/Wheezy, kernel 2.6.38, Postfix
I've had a procmail receipe in place for a few weeks now and it's been working well.
:0
- ^(TO|FROM):.+@mydomainname.*
{ :0c # Send a copy to the other email account. ! someone@anotherdomainname.com # File the original as normal :0 foldername }
OK... so that's about as informative as a melted chocolate tea pot that's got dog hair in it.
What about without the dog hair? Dark or Milk chocolate?
Then a few days ago, probably after some OS updates, it fails with:
status=deferred (host mail.*******.*****.com[000.00.00.0] said: 451 4.4.0 DNS temporary failure (chkuser) (in reply to MAIL FROM command))
(I've removed the data identifying the destination)
Yeah - I noticed - it's Really Not Useful if you're expecting sensible replies - yes, I know this is a public mailing list and is archived, but the bits that you've removed are exactly the bits we'd need to work out what's going on.
Well I'm not going to put those bits on a publicly available archived list. I can let you have details via a personal email if you want. The choice is yours.
I have also tried sending an email directly using /usr/bin/sendmail and that produces the same result, whatever the emails destination, so I'm assuming it must be my setup. I can't explain why it worked before but doesn't now though.
I have really no idea what this means as Postfix configuration is a series of magical incantaitions which I don't understand.
Some help would be much appreciated.
Why do you think it's you that's broken?
Because I've tried emailing, using sendmail directly, two entirely separate domains and it's failed both times with the same error. I've just tried another email to a third unrelated domain/account - same error.
Are you using a smarthost?
What's a smart host?
is the smart host the host that you've (convieniently... aka annoyingly so that no one can check anything for you...)
Do you really expect me to publicise email addresses for spammers to pick up?
edited out your own machine or somewhere else? Is it for the copy to someone@anotherdomainname.com?
mydomainname is the domain where incoming mail to my computer, collected using fetchmail, is coming from.
someone@anotherdomainname.com is an email account I've set up with my ISP specifically to redirect these copy emails to.
All emails sent, using my standard mailer (Balsa), are directed through my ISP i.e relayhost= in the Postfix main.cf file and don't give any errors/ problems. This current problem happens only when using /usr/sbin/sendmail directly which of course is what procmail does when forwarding a copy.
If it's for the copy, then I'd suggest that the domains MX server is having issues doing DNS lookups. As it says on the tin...
-- Brett Parker
On 02 Jun 17:22, Barry Samuels wrote:
On 02/06/11 13:43:31, Brett Parker wrote:
On 02 Jun 12:06, Barry Samuels wrote:
Then a few days ago, probably after some OS updates, it fails with:
status=deferred (host mail.*******.*****.com[000.00.00.0] said: 451 4.4.0 DNS temporary failure (chkuser) (in reply to MAIL FROM command))
(I've removed the data identifying the destination)
Yeah - I noticed - it's Really Not Useful if you're expecting sensible replies - yes, I know this is a public mailing list and is archived, but the bits that you've removed are exactly the bits we'd need to work out what's going on.
Well I'm not going to put those bits on a publicly available archived list. I can let you have details via a personal email if you want. The choice is yours.
OK - so, basically, what you're sending as the FROM address is getting rejected - you might need to do some address rewriting in postfix, or set the domain to something that actually exists in /etc/mailname.
I have also tried sending an email directly using /usr/bin/sendmail and that produces the same result, whatever the emails destination, so I'm assuming it must be my setup. I can't explain why it worked before but doesn't now though.
I have really no idea what this means as Postfix configuration is a series of magical incantaitions which I don't understand.
Some help would be much appreciated.
Why do you think it's you that's broken?
Because I've tried emailing, using sendmail directly, two entirely separate domains and it's failed both times with the same error. I've just tried another email to a third unrelated domain/account - same error.
Are you using a smarthost?
What's a smart host?
What relayhost is, basically.
is the smart host the host that you've (convieniently... aka annoyingly so that no one can check anything for you...)
Do you really expect me to publicise email addresses for spammers to pick up?
I'd almost bet if you google for the address it's already out there, but meh.
edited out your own machine or somewhere else? Is it for the copy to someone@anotherdomainname.com?
mydomainname is the domain where incoming mail to my computer, collected using fetchmail, is coming from.
someone@anotherdomainname.com is an email account I've set up with my ISP specifically to redirect these copy emails to.
All emails sent, using my standard mailer (Balsa), are directed through my ISP i.e relayhost= in the Postfix main.cf file and don't give any errors/ problems. This current problem happens only when using /usr/sbin/sendmail directly which of course is what procmail does when forwarding a copy.
Which won't (neccessarily) send from a valid e-mail address, and the relayhost is (correctly) rejecting it.
So, you want to make sure that the sending address is correctly qualified, the server is checking that, and then going "hang on, that address doesn't resolve".
in main.cf set myorigin = yourdomainname.com
assuming that there is an address of username@yourdomainname.com then that should fix the issue you're having.
Otherwise you'll be looking at using generic maps, which are *fun*.
-
Barry Samuels -
Brett Parker