Loading ...
Sorry, an error occurred while loading the content.

Re: Unable to set postfix as smarthost with plain authentication on port 25 (no tls/ssl): error 550 5.1.0 xxxxx authentication failed - SOLVED!

Expand Messages
  • Luca Arzeni
    Thanks Harald, for the sake of clarity I answered to you points in the mail, but after trying and retrying, it seems that I need to place:
    Message 1 of 2 , Feb 18, 2013
    • 0 Attachment
      Thanks Harald,
      for the sake of clarity I answered to you points in the mail, but after trying and retrying, it seems that I need to place:

      "smtp_sasl_mechanism_filter = plain"

      in the main.cf

      By forcing the mechanism the system is now able to connect to te server and send the mail.
      Thanks again, Luca

      On Thu, Feb 14, 2013 at 3:10 PM, Reindl Harald <h.reindl@...> wrote:

      Am 14.02.2013 14:48, schrieb Luca Arzeni:
      > I'm in need of using a smarthost to relay all of my mail.
      >
      > I'm unable to use an italia provider (aruba) as smarthos for my server.
      > I obtain the (in)famous "550 5.1.0 XXXXX authentication failed"

      maybe he does not like PLAIN without encryption
      why in the world would anybody do this?

      install "cyrus-sasl-md5" or however the package is called
      in your dsitribution and postfix will automatically use
      the best available method


      I can confirm that aruba smpt uses PLAIN authentication without encryption, so md5 (alas!) is not an option. I don't understand why they make this ugly thing, but "such is life!" (TM) :-)
       
      > I've tested username/password using thunderbird as client, it works

      with unencrypted plain auth?

      Yes it does work this way: unencrypted plain auth on port 25
       

      > I've tested the same configuration with another provider: it works.

      does not matter

      agreed. I was just pointing out that postfix is working and it's able to do a md5 authentication with other providers, so the problem is really in the unencrypted PLAIN authentication
       
      > My guess is that the provider uses different server to answer to my request

      how should it do this?

      > and so postfix is unable to find a matching password in
      > file /etc/postfix/sasl/saslpasswd.

      YOU control the match not the target server

      YOU control that host/port of the reylhost matchs EXACTLY
      how it is defined in "saslpasswd" and my guess is that
      you forgot to put the hostname inside [] to disable
      MX lookups

      I did use the [] but, as far as I can see, the logs shows that I ask for a server, but there are other names that I find in the logs. (placing a smptd -v in the master.conf)
       
      cat /etc/postfix/saslpasswd
      # CHANGES: postmap /etc/postfix/saslpasswd
      [mail.thelounge.net]:587 user:pwd

      > But I've tried by using smtp_cname_overrides_servername=yes or smtp_cname_overrides_servername=no and it failed in
      > the same way.

      don't do mangling around everywhere

      ok
       

      > I've also tried to declare all hostnames that I can see in the logs placing all of them in the
      > /etc/postfix/sasl/saslpasswd but even this way I cannot send my mail

      why are you doing this?

      also to be sure that there was a match between the entry in the saslpasswd file and the host.
      anyway: all well what ends well. 
      Thanks again, Luca
    • Luca Arzeni
      Thanks Bill, I will keep this behaviour next time. Anyway, but after trying and retrying, it seems that I need to place: smtp_sasl_mechanism_filter = plain
      Message 2 of 2 , Feb 18, 2013
      • 0 Attachment
        Thanks Bill,
        I will keep this behaviour next time.
        Anyway, but after trying and retrying, it seems that I need to place:

        "smtp_sasl_mechanism_filter = plain"

        in the main.cf

        By forcing the mechanism the system is now able to connect to te server and send the mail.
        Thanks again, Luca

        On Thu, Feb 14, 2013 at 11:05 PM, Bill Cole <postfixlists-070913@...> wrote:
        On 14 Feb 2013, at 8:48, Luca Arzeni wrote:

        Is there anyone that can help me?

        Maybe, maybe not. It is made less likely that anyone will be able to help by the fact that you ignored the advice sent to all subscribers to this list about how best to ask for help and get it.

        That advice is here: http://www.postfix.com/DEBUG_README.html#mail

        Specific to your request:

        1. You should be expansive rather than selective when posting logs. In this case you seem to have logged the whole SMTP chat, yet you only posted 2 lines. Earlier lines in this case would be critical to any analysis.

        2. Do not make any changes to log lines except to obscure truly security-sensitive information like authentication tokens or private email addresses. Hostnames and IP addresses are almost never worth obscuring and can be critical to figuring out a problem. In this case, you even asked about host identity and naming issues that we could help you with if you had not falsified what little evidence you provided.

        3. Including 'postconf -n' output is important because it shows all of the non-default configuration that Postfix actually uses. Citing a few settings without stating whether they came from main.cf or postconf output leaves open a broad range for conjecture and if you don't know how to correct your config, then your determination of what configuration is "relevant" is likely to be wrong.

        Some wild guesses on your difficulty:

        A. Your provider isn't offering an AUTH mechanism that your SASL config will use so there was no AUTH attempted, yet your provider requires it.

        B. Some idiot between your server and your provider has put a Cisco PIX or ASA in your path and turned on its 'smtp fixup' misfeature.

        C. There are errant/mismatched quotes and/or whitespace in your main.cf that results in a formally valid format that is not being parsed as you intend it to be.

        D. The main.cf file that you *think* Postfix is using is not the one it *is* using, due to a misconfigured chroot.

        My hunch is that there is about a 90% chance that your problem is caused by something else, but all of those unlikely possibilities could be eliminated (or confirmed) if you were to simply follow the instructions for seeking help here.

      Your message has been successfully submitted and would be delivered to recipients shortly.