This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SMTP relay not allowing anything in

First of all the error:

554 554 5.7.1 : Relay access denied (state 14).

The above is the error I get when trying to send externally to an internal address. (for example from gmail to a company address)

I've configured all the domains we use as well as set a static host list and pointed it to our exchange server at 192.168.0.1.

Is there any setting that might cause this to occur?

I had this occur on me whilst doing a live test today (end of day when everyone has gone home, plugged in the astaro 220 got everything working but incoming email.. obviously moved it back to the old firewall)

I'll do some further tests at work tomorrow (obviously), but any suggestions on where I might be going wrong are more than welcome.


This thread was automatically locked due to age.
Parents

  • 554 554 5.7.1 : Relay access denied (state 14).


    ASG does not produce such messages. Are you sure all the incoming mail arrives on the ASG?

    What is the real domain used? Please do not obsfucate.
  • Mark, I'm confused: does email get rejected with a "554 5.7.1" message, or does it come "straight though"?

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Mark, I'm confused: does email get rejected with a "554 5.7.1" message, or does it come "straight though"?

    Cheers - Bob


    Do you mean is it giving the error to the sender but still being received by the recipient? In which case no, it's giving the sender the error and the recipient is getting nothing.

    I did a different test last night as well, this is from another email provider in its entirety. (true email address changed to avoid spam harvesters)



    --ApZbf.4MJbZusrh.1wQDdh.YPHSVr
    content-type: text/plain;
        charset="iso-8859-1"
    Content-Transfer-Encoding: quoted-printable

    The following message to  was undeliverable.
    The reason for the problem:
    5.1.0 - Unknown address error 554-'5.7.1 : Relay =
    access denied'

    --ApZbf.4MJbZusrh.1wQDdh.YPHSVr
    content-type: message/delivery-status

    Reporting-MTA: dns; mk-outboundfilter-3.mail.uk.tiscali.com

    Final-Recipient: rfc822;abc@jadeprint.com
    Action: failed
    Status: 5.0.0 (permanent failure)
    Remote-MTA: dns; [194.217.242.9]
    Diagnostic-Code: smtp; 5.1.0 - Unknown address error 554-'5.7.1 : Relay access denied' (delivery attempts: 0)

    --ApZbf.4MJbZusrh.1wQDdh.YPHSVr
    content-type: message/rfc822

    Received: from mk-nildram-webmail-1.uk.tiscali.com (HELO UebiMiau) ([212.139.135.3])
      by smtp.f2s.tiscali.co.uk with SMTP; 14 Oct 2008 17:48:48 +0100
    Received: from mk-nildram-webmail-1.uk.tiscali.com (HELO UebiMiau) ([212.139.135.3])
      by smtp.f2s.tiscali.co.uk with SMTP; 14 Oct 2008 17:48:48 +0100
    Received: from client 62.49.116.50 for UebiMiau2.7 (webmail client); Tue, 14 Oct 2008 17:48:47 +0100
    Date: Tue, 14 Oct 2008 17:48:47 +0100
    From: "abc" 
    X-Webmail-User: 43454b3b3b4235566479547221654e4a4b7e652054
    To: abc@jadeprint.com
    Reply-to: "abc" 
    Subject: test
    X-Priority: 3
    X-Mailer: UebiMiau 2.7.2
    X-Original-IP: 62.49.116.50
    Content-Transfer-Encoding: 8bit
    Return-Path: abc@gotadsl.co.uk
    X-MSMail-Priority: Medium
    Importance: Medium
    Content-Type: text/plain; charset="iso-8859-1";
    MIME-Version: 1.0

    test

    ________________________________________________
    Message sent using UebiMiau 2.7.2


    --ApZbf.4MJbZusrh.1wQDdh.YPHSVr--


    I've just installed astaro in vmware workstation, so I've started experimenting without the fear of breaking the 220 demo hardware.

    I'm approaching this slightly different as to how it was recommended to me, using the wizard this time.
  • Mark,

    Check that your reverse DNS record is correct.  As an experiment, what happes if you uncheck BATV?

    And, I still don't understand how you received an email from your gmail account if email from gmail is rejected...

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Looks like you have 3 entries for mx records. From the IP provided in your mail headers, the denying mta is at 194.217.242.9 (your second mx relay-1.mail.demon.net). This is the relay that is denying your mail not astaro.

    All your mail should be going to the first mx but its not so your astaro is not live on the net for some reason if that is your first mx.

    HTH[:D]
  • Mark,

    Check that your reverse DNS record is correct.  As an experiment, what happes if you uncheck BATV?

    And, I still don't understand how you received an email from your gmail account if email from gmail is rejected...

    Cheers - Bob


    I didn't receive any email from gmail, just the 554 gmail generated error.

    Apologies as I'm typing this up on my iPhone, so sorry for the short reply.

    As to other mx's if it was being rejected a that point then surely it wouldn't work with our current firewall?

    Also, I've had the thought that incoming emails come to 62.49.116.52 whilst the firewalls ip is 62.49.116.50, however we've got a netmask of 255.255.255.248 so it shouldn't matter. Right?
Reply
  • Mark,

    Check that your reverse DNS record is correct.  As an experiment, what happes if you uncheck BATV?

    And, I still don't understand how you received an email from your gmail account if email from gmail is rejected...

    Cheers - Bob


    I didn't receive any email from gmail, just the 554 gmail generated error.

    Apologies as I'm typing this up on my iPhone, so sorry for the short reply.

    As to other mx's if it was being rejected a that point then surely it wouldn't work with our current firewall?

    Also, I've had the thought that incoming emails come to 62.49.116.52 whilst the firewalls ip is 62.49.116.50, however we've got a netmask of 255.255.255.248 so it shouldn't matter. Right?
Children
  • Billybob's got it right.  Your Astaro isn't receiving emails.  It's only telling the world that x.x.x.50 is available, so your emails are going to your second mx.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • I
    As to other mx's if it was being rejected a that point then surely it wouldn't work with our current firewall?
    255.255.255.248 so it shouldn't matter. Right?


    Its not as to other, IT IS your mx2 that is rejecting the mail according to the snippet you sent. You can bang your head against other things but that is the one that rejected the email that you provided. Maybe a configuration check on mx2 is in order?
  • Regarding the mx stuff, I've just gone over the domains and have added the demon and netbenefit mx addresses. I will come in to work early tomorrow morning and try again.

    I can only do these tests on our line when nobody is in.
  • Its not as to other, IT IS your mx2 that is rejecting the mail according to the snippet you sent. You can bang your head against other things but that is the one that rejected the email that you provided. Maybe a configuration check on mx2 is in order?


    Our second mx record is: 100 relay-1.mail.demon.net 194.217.242.207

    Immediately after our main: 10 mailgate.jadeprint.com 62.49.116.50

    The only thing I'm thinking of now is perhaps it timed out trying to connect to the primary mx, sent it to the secondary and because the secondary mx record address wasn't in astaro's relaying settings it was rejected?

    Looking at what I posted closer I think that occurred, even though the priority is higher for ours (62.49.116.50) it got delivered to demons mx at 194.217.242.9 which tried to deliver the mail, but because that address wasn't in astaro it got rejected.

    The culprit: "Remote-MTA: dns; [194.217.242.9]"


    Thanks for the help, I'd totally forgotten to take into account mx records. Hopefully when I try it tomorrow morning it should work.

    EDIT: The third mx record is 100 relay-2.mail.demon.net 194.217.242.9 (just adding this for posterity)
  • The IP of the MX should be available on the external interface of your firewall.
    Having an IP + netmask that covers that range won't help you. 

    You need to setup the MX IP as an additional IP address on the external interface.

    Try telnetting to the MX record IP on port 25 and see if you get an SMTP answer.
  • The IP of the MX should be available on the external interface of your firewall.
    Having an IP + netmask that covers that range won't help you. 

    You need to setup the MX IP as an additional IP address on the external interface.

    Try telnetting to the MX record IP on port 25 and see if you get an SMTP answer.


    Ah, I think I should elaborate. The firewalls external interface is 62.49.116.50/29. So since it's already running on 62.49.116.50 I shouldn't need to add an additional address correct?

    Curiously I did telnet into port 25 and here's the output:

    =~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2008.10.15 16:41:55 =~=~=~=~=~=~=~=~=~=~=~=
    
    HELO test.com
    554 SMTP synchronization error


    There was a massive pause regardless of what I type and then the error.

    However, it might be giving that error because it wasn't connected to the real network with the actual email server on. Therefore it's trying to make a connection with the email server and cannot hence "SMTP synchronization error".

    This was done from a machine directly connected up to the firewall and telnet'd into it (to 62.49.116.50 from 192.168.0.2) from that on the lan port.

    When I connect the 220 to the network tomorrow i'll try the above test from my home machine and from the lan, see if it gives me anything different.
  • Looks like the primary mx is answering but its still not astaro

    Here are the telnet headers
    [billybob@Xena var]$ telnet  mailgate.jadeprint.com 25
    Trying 62.49.116.50...
    Connected to mailgate.jadeprint.com (62.49.116.50).
    Escape character is '^]'.
    220 SMTP ready.
    helo me
    250 OK
    mail from: me@jadeprint.com
    250 OK
    rcpt to: postmaster@jadeprint.com
    250 OK
    data
    354 Enter mail, end with "." on a line by itself
  • Looks like the primary mx is answering but its still not astaro

    Here are the telnet headers
    [billybob@Xena var]$ telnet  mailgate.jadeprint.com 25
    Trying 62.49.116.50...
    Connected to mailgate.jadeprint.com (62.49.116.50).
    Escape character is '^]'.
    220 SMTP ready.
    helo me
    250 OK
    mail from: me@jadeprint.com
    250 OK
    rcpt to: postmaster@jadeprint.com
    250 OK
    data
    354 Enter mail, end with "." on a line by itself


    Um, yes. As I said I haven't connected up the astaro. The old firewall is still up and running. The astaro will be put in for roughly an hour early tomorrow morning as a test.

    So that's roughly 13 to 15 hours away.
  • There may be some capability that I ignore, but I don't believe the Astaro will work correctly if the IP is configured as '62.49.116.50/29'.  Others will please correct me if I'm wrong, but I believe you have to configure the interface as 62.49.116.50, then add 62.49.116.51-57 (each individually!) as 'Additional Addresses' on the External inteface.

    If you want to treat the 62.49.116.50/29 block as a single entity for packet filter rules or someother, you can create a 'Network Group' in 'Definitions >> Networks'.

    Markcasey, you sound knowledgeable, but I wonder if you aren't thinking in a Cisco command-line paradigm.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • It seemed to work fine, although when I connected in on telnet to port 25 from the lan to the firewall it got dropped out with "554 SMTP synchronization error" immediately. (I forgot to try and connect in remotely on telnet from my home machine)

    So I'm provisionally saying emails now work. (I only had it connected up for a short period before I had to quickly reconnect the current firewall, but some emails seemed to have come through ok)

    I've now got a fairly comprehensive configuration going, need to work on L2TP VPN for the iPhones next...