Re: [SLE] Postfix question

From: Theo v. Werkhoven (twe-suse.e_at_ferrets4me.xs4all.nl)
Date: 09/20/04

  • Next message: Randall R Schulz: "Re: [SLE] wget question"
    Date: Mon, 20 Sep 2004 19:24:36 +0200
    To: suse-linux-e@suse.com
    
    
    

    Mon, 20 Sep 2004, by usr@sanctum.com:

    > On Sunday 19 September 2004 02:49, Jeffrey L. Taylor wrote:
    > >Quoting Bob S <usr@sanctum.com>:
    > >> Hello SuSE people,
    > >>
    > >> Have a question about Postfix. Back about the 9th or 10th I upgraded
    > >> KDE to 3.3. That included Kmail which is my only e-mail program.
    > >
    > >You need to have some kind of Mail Transfer Agent (MTA) like Postfix
    > >on most Linux systems. It looks like it is not correctly setup,
    > >though there are other possibilities like your ISP is blocking outgoing
    > >mail that bypasses their SMTP servers, a common attempt at reducing
    > >SPAM, especially from zombies/trojans. Linux.local may be your
    > >machine, check the IP address.
    > >
    >
    > Thanks to all who contributed to this question. Simple question generated
    > quite a large response and as a result I learned quite a bit. Do have a few
    > specific questions from the various responses.
    >
    > Jeffrey, Sent off an email to my ISP tonight asking about the blocking and/or
    > the POP before SMTP thing. Will let the list know their response.
    >
    > Theo, you stated:
    > >That's not the problem, the problem was a DNS lookup failure
    > >according to the bounce message, Postfix couldn't find a place to
    > >drop the mail because the DNS didn't give it one, and so it returned
    > >the mail to sender.
    > Please elaborate. Where and why couldn't Postfix find the DNS. The DNS for my
    > ISP ? or for the recipient? And if so how do I check it? The DNS for my ISP
    > is defined in PPP someplace.

    It wasn't that Postfix couldn't find a DNS, but the DNS didn't
    answer the query that the DNS received from Postfix, and so POstfix
    didn't know where to drop off the mail.

    That's the way mail servers work: a user wants to send a mail to
    user@example.com. Postfix gets the mail from the Mail User Agent
    (the mail client program like e.g. kmail), looks at the recipient
    address (example.com) and tries to find out which mail host is
    responsible for the example.com domain.
    Postfix does this by first asking root DNS servers for what DNS knows
    anything about the .com top level domain, then it asks the first
    responding server what DNS knows about example.com domain, and if
    Postfix got that address it asks example.com what host receives the
    mail for example.com.
    If Postfix finally knows the answer (e.g. mail.example.com) then it
    can send the mail on to its destination.
    If one of the DNS server doesn't answer (usually the one responsible
    for the domain), the request from Postfix times out and the mail
    never gets send.
    In your case the DNS responsible for .com tld didn't know
    esupport.com, so the query ended there.

    You can check with 'dig -t mx example.com' if your 'resolver' can
    find the Mail eXchange record for example.com.

    > Now, if I read the posts from Theo, I do not NEED an MTA - OK - understood ??

    Not one running as daemon, if all you do is Desktop stuff, no.

    > But I DO have Postfix. According to Patrick Postfix is needed internally by
    > SuSE for things like mail for root etc. Good- OK Carlos says that Kmail
    > actually uses Postfix to send it's mail. ( required?) And Patrick agrees,
    > stating: >"Yes, he is mixing daemon with MTA.  The MTA is still
    > required/installed." ----- Or, only if it is there to use? But Kmail can
    > actually do it all by itself? A little confused here !!

    Kmail has it's own SMTP engine, and doesn't need an external mail
    server like e.g. Mutt.
    You can set your ISP's mail gateway address in kmail and drop the
    mail directly into their care.
    For system messages you wish to receive you do need a MTA though.

    Theo

    -- 
    Theo v. Werkhoven    Registered Linux user# 99872 http://counter.li.org
    ICBM 52 13 27N , 4 29 45E.     +      ICQ: 277217131
    SUSE 9.1                       +   Jabber: gurp@nedlinux.nl
    Kernel 2.6.5                   +      MSN: twe-msn@ferrets4me.xs4all.nl
    See headers for PGP/GPG info.  +
    
    


    • application/pgp-signature attachment: stored

  • Next message: Randall R Schulz: "Re: [SLE] wget question"

    Relevant Pages

    • [NEWS] Cisco Content Service Switch 11000 Series DNS Negative Cache of Information Denial-of-Service
      ... respond to certain Domain Name Service (DNS) name server record requests ... Global Server Load Balancing. ... This vulnerability in CSS is documented as Cisco Bug IDs CSCdz62499 and ... formulate a response for the client. ...
      (Securiteam)
    • Re: VPN generates Internal Network logon problem
      ... I am sorry for the delayed response due to weekend. ... However there are 4004 and 4015 DNS errors in the event log. ... 825763 How to configure Internet access in Windows Small Business Server ... Microsoft CSS Online Newsgroup Support ...
      (microsoft.public.windows.server.sbs)
    • Re: DNS drops out Windows 2003 Sever
      ... Thanks for your response. ... A correction to my initial post...all DNS queries are affected, ... > 830381 - Server Responsiveness Degrades and Queries Time Out When You Run ...
      (microsoft.public.windows.server.dns)
    • Re: How to disable the "implicit mx record" in Exchange
      ... the host with the A record for the actual domain. ... So when Exchange gets a DNS timeout looking up an MX record, ... our ISP's DNS and perhaps slow response from the recipient domain's ... their own Exchange or other type of mail server under their own domain name, ...
      (microsoft.public.exchange.admin)
    • Re: [SLE] Postfix question
      ... >>drop the mail because the DNS didn't give it one, ... Where and why couldn't Postfix find the DNS. ... The DNS for my ISP ... This DNS could not find the name postfix wanted to find, or the DNS server ...
      (SuSE)