I bought myself a new computer at the end of last week to replace my aging 32 bit machine. I decided to install Debian Testing/Jessie 64 bit from scratch and set it up to match, roughly, what was on my old machine.
I included Postfix which was on my 32 bit machine on the assumption that I could copy the Postfix configuration across and it would work. I have to admit that I find email configuration to be one of the black arts which uses magic incantations.
Needless to say it didn't work. After a bit of research I discovered that putting 'inet_protocols = ipv4' in main.cf enabled me to send emails.
Some of the sent emails appear to get to their intended destinations and some don't with messages as under:
mywife@gmail.com: host mx1.spamfiltering.com[212.113.130.124] said: 550 relay not permitted! (in reply to RCPT TO command)
me@myaddress.co.uk: host mx1.spamfiltering.com [72.249.150.158] said: 550 81.151.115.33 is listed on sem-black.rbl.spamrl.com. Please organise removal and retry. (in reply to end of DATA command)
I have obscured some of the details but it should still give an idea. the ip address 81.151.115.33 is btinternet.com our ISP.
Similar emails sent from my old machine don't produce those error messages.
Any suggestions would be much appreciated.
On 04/08/14 20:33, Barry Samuels wrote:
I bought myself a new computer at the end of last week to replace my aging 32 bit machine. I decided to install Debian Testing/Jessie 64 bit from scratch and set it up to match, roughly, what was on my old machine.
I included Postfix which was on my 32 bit machine on the assumption that I could copy the Postfix configuration across and it would work. I have to admit that I find email configuration to be one of the black arts which uses magic incantations.
Needless to say it didn't work. After a bit of research I discovered that putting 'inet_protocols = ipv4' in main.cf enabled me to send emails.
Some of the sent emails appear to get to their intended destinations and some don't with messages as under:
mywife@gmail.com: host mx1.spamfiltering.com[212.113.130.124] said: 550 relay not permitted! (in reply to RCPT TO command)
For this one, more info is required. How are you trying to relay email? Via BT? Directly? From the above it seems you're trying to relay through 212.113.130.124. If that's the intended behaviour, maybe you need to authenticate first.
me@myaddress.co.uk: host mx1.spamfiltering.com [72.249.150.158] said: 550 81.151.115.33 is listed on sem-black.rbl.spamrl.com. Please organise removal and retry. (in reply to end of DATA command)
I have obscured some of the details but it should still give an idea. the ip address 81.151.115.33 is btinternet.com our ISP.
This is saying that 81,blah is on a blacklist. BT need to fix that. However, is that the IP address of a BT relay or is it your DSL dynamic address? If the latter, many SMTP relays refuse to accept traffic from them, and you need to route via your ISP's relay.
To do that, you need to put:
relayhost = smtp.example.com
in your main.cf
Similar emails sent from my old machine don't produce those error messages.
What are the respective versions of postfix?
Any suggestions would be much appreciated.
The above two errors appear to be contradictory!
Cheers, Laurie.
On 5 August 2014 08:37, Laurie Brown laurie@brownowl.com wrote:
The above two errors appear to be contradictory!
That was my first thought.
However, there are two IP addresses given here for mx1.spamfiltering.com, and a quick DNS lookup confirms that there are indeed two A records. This would suggest that outbound email is being relayed via mx1.spamfiltering.com and that those two servers are perhaps configured differently (maybe same rules in different order, or different rules, or same rules but the 550 responses aren't set the same - from experience I don't trust the text that follows the 550 response to always bare any relationship to the real reason the email was rejected).
But copying the postfix config between machines may have left out the authentication settings, and would thus explain why it worked on one machine and fails on the next. There ought to be clues in /var/log/mail.log.
As an aside: unless things have changed, BT Internet mess around with SMTP traffic (and it can vary depending on which of their servers you hit). I seem to recall that attempts to use unencrypted SMTP on port 25 would (sometimes) get proxied to their servers, and that frequently they'd block any attempts to send mail from your own domain names in an attempt to block spam (?!*). I daresay some of these policies have changed since I last looked and they don't seem relevant here, but I would certainly suggest that postfix should be sending encrypted email to an authenticated mail relay if for no other reason that to bypass BT (there are lots of better reasons to be doing that anyway).
[?!*] "Blocking spam" didn't seem to be necessary on business accounts, but I'm not so bold as to suggest that this was really just about forcing anyone savvy enough to own their own domain to use a business account.
Mark
On 05/08/14 09:06:00, Mark Rogers wrote:
On 5 August 2014 08:37, Laurie Brown laurie@brownowl.com wrote:
The above two errors appear to be contradictory!
That was my first thought.
However, there are two IP addresses given here for mx1.spamfiltering.com, and a quick DNS lookup confirms that there are indeed two A records. This would suggest that outbound email is being relayed via mx1.spamfiltering.com and that those two servers are perhaps configured differently (maybe same rules in different order, or different rules, or same rules but the 550 responses aren't set the same - from experience I don't trust the text that follows the 550 response to always bare any relationship to the real reason the email was rejected).
As far as I know spamfiltering.com is used only for incoming mail (it is United Hosting's spam trap (see reply to Laurie) and outgoing mail is not directed to that.
But copying the postfix config between machines may have left out the authentication settings, and would thus explain why it worked on one machine and fails on the next. There ought to be clues in /var/log/mail.log.
The whole of the Postfix directory was copied so I don't think that anything was left out.
I can't see any clues in /var/mail.log but then I don't know really what I'm looking for.
As an aside: unless things have changed, BT Internet mess around with SMTP traffic (and it can vary depending on which of their servers you hit). I seem to recall that attempts to use unencrypted SMTP on port 25 would (sometimes) get proxied to their servers, and that frequently they'd block any attempts to send mail from your own domain names in an attempt to block spam (?!*). I daresay some of these policies have changed since I last looked and they don't seem relevant here, but I would certainly suggest that postfix should be sending encrypted email to an authenticated mail relay if for no other reason that to bypass BT (there are lots of better reasons to be doing that anyway).
BTInternet are our ISP but our email does not go through them.
[?!*] "Blocking spam" didn't seem to be necessary on business accounts, but I'm not so bold as to suggest that this was really just about forcing anyone savvy enough to own their own domain to use a business account.
Mark
On 5 August 2014 10:45, Barry Samuels bjsamuels@beenthere-donethat.org.uk wrote:
As far as I know spamfiltering.com is used only for incoming mail (it is United Hosting's spam trap (see reply to Laurie) and outgoing mail is not directed to that.
In both the error messages you posted, you had the text: "host mx1.spamfiltering.com[x.x.x.x] said:" ... where x.x.x.x was one of the two IP addresses that mx1.spamfiltering.com resolves to:
$ dig mx1.spamfiltering.com ... ;; ANSWER SECTION: mx1.spamfiltering.com. 437 IN A 72.249.150.158 mx1.spamfiltering.com. 437 IN A 212.113.130.124
That doesn't mean it's being spam filtered on exit though, just that the server they're using for relaying has one of those addresses.
The whole of the Postfix directory was copied so I don't think that anything was left out.
It's been a while since I set up Postfix but let's say for example that the SASL configuration was broken because something wasn't properly installed. The configuration might be telling Postfix to use it, but if it's not there (or otherwise broken) it can't. It may well then be that Postfix drops back to a different option (much as it might if the "other end" didn't support SASL), and that different option is triggering the errors that you're not seeing on your other box. Ie same config, but different results.
I can't see any clues in /var/mail.log but then I don't know really what I'm looking for.
Best option is to send test emails from each box to the same recipient (one that fails) and compare the logs for the same event on both boxes. Anything that is different is likely a clue.
BTInternet are our ISP but our email does not go through them.
That does appear to be the case here, but it was more a note to be aware that BT doesn't always do what you think it does. It is quite possible that you (try to) make a connection to your mail server on port 25, and BT proxies (redirects) that connection to their own mail servers. You can test this using telnet: $telnet <my remote SMTP server> 25 .. and see what response you get; if it comes from BT then BT are silently redirecting your connection.
But again just to stress this: nothing indicates that is happening here because the responses you are getting aren't coming from BT.
Mark
On 05/08/14 11:19:41, Mark Rogers wrote:
On 5 August 2014 10:45, Barry Samuels bjsamuels@beenthere-donethat.org.uk wrote:
As far as I know spamfiltering.com is used only for incoming mail (it is United Hosting's spam trap (see reply to Laurie) and outgoing mail is not directed to that.
In both the error messages you posted, you had the text: "host mx1.spamfiltering.com[x.x.x.x] said:" ... where x.x.x.x was one of the two IP addresses that mx1.spamfiltering.com resolves to:
$ dig mx1.spamfiltering.com ...;; ANSWER SECTION: mx1.spamfiltering.com. 437 IN A 72.249.150.158 mx1.spamfiltering.com. 437 IN A 212.113.130.124
That doesn't mean it's being spam filtered on exit though, just that the server they're using for relaying has one of those addresses.
The whole of the Postfix directory was copied so I don't think that anything was left out.
It's been a while since I set up Postfix but let's say for example that the SASL configuration was broken because something wasn't properly installed. The configuration might be telling Postfix to use it, but if it's not there (or otherwise broken) it can't. It may well then be that Postfix drops back to a different option (much as it might if the "other end" didn't support SASL), and that different option is triggering the errors that you're not seeing on your other box. Ie same config, but different results.
I've checked sasl packages on both machines and the only difference is that there is libgsasl7 installed on the new machine but not on the old.
I did try re-doing postmap sasl_passwd but that made no difference.
I can't see any clues in /var/mail.log but then I don't know really what I'm looking for.
Best option is to send test emails from each box to the same recipient (one that fails) and compare the logs for the same event on both boxes. Anything that is different is likely a clue.
BTInternet are our ISP but our email does not go through them.
That does appear to be the case here, but it was more a note to be aware that BT doesn't always do what you think it does. It is quite possible that you (try to) make a connection to your mail server on port 25, and BT proxies (redirects) that connection to their own mail servers. You can test this using telnet: $telnet <my remote SMTP server> 25 .. and see what response you get; if it comes from BT then BT are silently redirecting your connection.
The response comes from my email server at United Hosting so no redirecting there.
But again just to stress this: nothing indicates that is happening here because the responses you are getting aren't coming from BT.
Mark
Mark Rogers // More Solutions Ltd (Peterborough Office) // 0844 251 1450 Registered in England (0456 0902) @ 13 Clarke Rd, Milton Keynes, MK1 1LG
main@lists.alug.org.uk http://www.alug.org.uk/ http://lists.alug.org.uk/mailman/listinfo/main Unsubscribe? See message headers or the web site above!
As a matter of interest I have changed outgoing mail to use mail.btinternet.com and it all seems to work perfectly now.
That, to me, implies a problem with United Hosting's servers although it doesn't explain why it still works perfectly on my old machine. I am in touch with United Hosting about this but they haven't yet come up with anything useful.
On 5 August 2014 11:51, Barry Samuels bjsamuels@beenthere-donethat.org.uk wrote:
As a matter of interest I have changed outgoing mail to use mail.btinternet.com and it all seems to work perfectly now.
That, to me, implies a problem with United Hosting's servers although it doesn't explain why it still works perfectly on my old machine. I am in touch with United Hosting about this but they haven't yet come up with anything useful.
The combination of information you've given suggest to me that for some reason authentication was working before but is not working now.
A mail server that you try to relay through without authentication would respond the way you are seeing. It would likely, however, accept and deliver mail that it didn't need to forward (eg to other users on the same server).
On the other hand an ISP's mail server will generally accept all mail from their client's IP addresses without authentication. (Downside is that you have to live with whatever policies they implement, and if your PC is actually a laptop it will all break as soon as you move to a location outside your ISP's address range.)
I would be interested to know if the old PC works after you set it to use BT's relay. If it is authenticating correctly now, changing it to use BT's relay should fail (as the user/pass you have configured won't be accepted by BT's server), although it may just fallback to unauthenticated.
I still think that your logs should give you the answer - same test on both old and new PCs and see how the logs differ. Even if there are no obvious errors this should tell you what they're doing differently.
Mark
On 05/08/14 15:00:48, Mark Rogers wrote:
On 5 August 2014 11:51, Barry Samuels bjsamuels@beenthere-donethat.org.uk wrote:
As a matter of interest I have changed outgoing mail to use mail.btinternet.com and it all seems to work perfectly now.
That, to me, implies a problem with United Hosting's servers although
it
doesn't explain why it still works perfectly on my old machine. I am
in
touch with United Hosting about this but they haven't yet come up with anything useful.
The combination of information you've given suggest to me that for some reason authentication was working before but is not working now.
A mail server that you try to relay through without authentication would respond the way you are seeing. It would likely, however, accept and deliver mail that it didn't need to forward (eg to other users on the same server).
On the other hand an ISP's mail server will generally accept all mail from their client's IP addresses without authentication. (Downside is that you have to live with whatever policies they implement, and if your PC is actually a laptop it will all break as soon as you move to a location outside your ISP's address range.)
I would be interested to know if the old PC works after you set it to use BT's relay. If it is authenticating correctly now, changing it to use BT's relay should fail (as the user/pass you have configured won't be accepted by BT's server), although it may just fallback to unauthenticated.
I still think that your logs should give you the answer - same test on both old and new PCs and see how the logs differ. Even if there are no obvious errors this should tell you what they're doing differently.
Mark
United Hosting seem to think that it is/was a DNS caching problem. They gave me another server address to use which I tried and it all seemed to work so they suggested going back to the original mail server and trying again. I am now back on the old mail server address and all seems to be working.
Having gone from the original to BT to New and then back to original must have cleared the DNS cache (somewhere) as, assuming this gets to ALUG, it's all working as it should.
On 05/08/14 08:37:19, Laurie Brown wrote:
On 04/08/14 20:33, Barry Samuels wrote:
I bought myself a new computer at the end of last week to replace my aging > > 32 bit machine. I decided to install Debian Testing/Jessie 64 bit from scratch and set it up to match, roughly, what was on my old machine. I included Postfix which was on my 32 bit machine on the assumption that I could copy the Postfix configuration across and it would work. I have to admit that I find email configuration to be one of the black arts which uses magic incantations.
Needless to say it didn't work. After a bit of research I discovered that putting 'inet_protocols = ipv4' in main.cf enabled me to send emails.
Some of the sent emails appear to get to their intended destinations and some don't with messages as under:
mywife@gmail.com: host mx1.spamfiltering.com[212.113.130.124] said: 550 relay not permitted! (in reply to RCPT TO command)
For this one, more info is required. How are you trying to relay email? Via BT? Directly? From the above it seems you're trying to relay through 212.113.130.124. If that's the intended behaviour, maybe you need to authenticate first.
Outgoing mail is directed to my mail server which is part of the web hosting package from United Hosting. Postfix is set up to use sasl (another of the Black Arts) with appropriate authentication.
The Postfix configuration was copied from the old machine, which worked without problems, to the new machine.
me@myaddress.co.uk: host mx1.spamfiltering.com [72.249.150.158] said: 550 81.151.115.33 is listed on sem-black.rbl.spamrl.com. Please organise removal and retry. (in reply to end of DATA command)
I have obscured some of the details but it should still give an idea. the ip address 81.151.115.33 is btinternet.com our ISP.
This is saying that 81,blah is on a blacklist. BT need to fix that.
I don't think that the IP address is on a blacklist because mail from the old machine doesn't produce that error.
However, is that the IP address of a BT relay or is it your DSL dynamic address? If the latter, many SMTP relays refuse to accept traffic from them, and you need to route via your ISP's relay.
To do that, you need to put:
relayhost = smtp.example.com
in your main.cf
That IP addrress is the dynamic address of our router and the entry in main.cf is to my mail server at United Hosting as detailed above and, again, the Postfix configuration is the same on both machines and the old machine doesn't produce that error.
Similar emails sent from my old machine don't produce those error messages.
What are the respective versions of postfix?
The versions are identical. The only differences being that the old is 32 bit and the new is 64 bit and the new version of Debian was set up last week and the original version of Debian on the old machine was set up years ago with regular updates.
Any suggestions would be much appreciated.
The above two errors appear to be contradictory!
Cheers, Laurie.
-
Barry Samuels -
Laurie Brown -
Mark Rogers