Menu
▾
▴
fetchmail-users
|
From: M. F. <mfi...@ne...> - 2007-08-16 14:56:15
|
On Thu, Aug 16, 2007 13:12:41 PM +0100, Rob MacGregor (rob...@gm...) wrote: > On 8/16/07, M. Fioretti <mfi...@ne...> wrote: > Please upgrade to 6.3.8 The one I reported is the default one in Centos 4.4, I'll try to have it upgraded asap, thanks. Not that it would make any difference wrt this problem, would it? Now: > > Helo command rejected: need fully-qualified hostname > So, fix your postfix configuration As I mentioned in the original message, I cannot easily change (for reasons which are everything but technical...) the postfix configuration. Unless I *am* sure that it is really the only possible way to fix this, that is. Otherwise I would have posted straight to the postfix list. For the record, here is the complete excerpt of the postfix refusal I get _WITH_: poll pop3.myprovider.com with proto POP3 tracepolls user myaccount there with pass "the password" is root here keep smtpaddress exact_output_of_hostname_command_here Aug 16 14:41:55 machinename postfix/smtpd[5641]: NOQUEUE: reject: RCPT from localhost[127.0.0.1]: 504 5.5.2 <localhost>: Helo command rejected: need fully-qualified hostname; from=<testaddress> to=<root@exact_output_of_hostname_command_here> proto=ESMTP helo=<localhost> I take this to mean that setting smtpaddress as above isn't enough to not make fetchmail send an helo different than localhost. Is this correct, and if yes, isn't there any other way to make fetchmail helo something else? With respect to this: > Having taken 2 seconds to consult the postfix documentation.. I suspect > you actually want to further consult the postfix documentation Generally, I have no problem at all to study man pages. The specific problem I have with email related docs is that it's really hard to figure out, unless one already knows the whole terminology and protocols in advance, to know what to search for. Even placing the whole error message in google, as I usually do, doesn't yeld much when email is concerned. I know this for a fact, that's why I also need a bit of pointers from mailing lists. Thanks for your patience, Marco -- Help *everybody* love Free Standards and Software: http://digifreedom.net |
|
From: Rob M. <rob...@gm...> - 2007-08-16 16:08:35
|
On 8/16/07, M. Fioretti <mfi...@ne...> wrote:
>
> The one I reported is the default one in Centos 4.4, I'll try to
> have it upgraded asap, thanks. Not that it would make any difference wrt
> this problem, would it? Now:
It probably wouldn't, but I don't know all the changes that have gone
into fetchmail in the interim.
> I take this to mean that setting smtpaddress as above isn't enough to
> not make fetchmail send an helo different than localhost. Is this correct,
> and if yes, isn't there any other way to make fetchmail helo something
> else?
Right, having taken a moment to dive into the code, the value of the
HELO/ELHO string that is presented is the value of smtphost. This
defaults to localhost - change this to the fully qualified name of the
host and ensure that it is configured to NOT reject connections that
provide it's own name as the HELO value.
Note that rejecting unqualified HELO values while being fully RFC
compliant will trip up a large number of MUAs (particularly those from
Microsoft). If you don't expect any mail clients to ever connect
directly you'll probably be ok.
> Generally, I have no problem at all to study man pages. The specific
> problem I have with email related docs is that it's really hard to
> figure out, unless one already knows the whole terminology and protocols
> in advance, to know what to search for.
>
> Even placing the whole error message in google, as I usually do, doesn't
> yeld much when email is concerned. I know this for a fact, that's why I
> also need a bit of pointers from mailing lists.
Which is why I went directly to the postfix site for that snippet, and
I don't even use postfix :)
--
Please keep list traffic on the list.
Rob MacGregor
Whoever fights monsters should see to it that in the process he
doesn't become a monster. Friedrich Nietzsche
|
|
From: Frederic M. <fre...@wo...> - 2007-08-16 16:20:41
|
M. Fioretti a écrit : >>> Helo command rejected: need fully-qualified hostname >>> >> So, fix your postfix configuration >> > > As I mentioned in the original message, I cannot easily change (for > reasons which are everything but technical...) the postfix configuration. > Unless I *am* sure that it is really the only possible way to fix this, that > is. Otherwise I would have posted straight to the postfix list. > > For the record, here is the complete excerpt of the postfix refusal I get > _WITH_: > > poll pop3.myprovider.com with proto POP3 tracepolls > user myaccount there with pass "the password" is root here keep > smtpaddress exact_output_of_hostname_command_here > > Aug 16 14:41:55 machinename postfix/smtpd[5641]: NOQUEUE: reject: RCPT > from localhost[127.0.0.1]: 504 5.5.2 <localhost>: Helo command rejected: > need fully-qualified hostname; from=<testaddress> > to=<root@exact_output_of_hostname_command_here> proto=ESMTP > helo=<localhost> > > I take this to mean that setting smtpaddress as above isn't enough to > not make fetchmail send an helo different than localhost. Is this correct, > and if yes, isn't there any other way to make fetchmail helo something > else? > According to fetchmail's man page smtpaddress adds the domain to the rcpt to, not to the helo of the envelope. Have a look at your /etc/hosts. Does the address 127.0.0.1 resolves first to the name of the machine or to localhost as is usually the case by default ? If localhost is the first name, could you rewrite /etc/hosts to put the machine name (what you want to see in the helo) as the first name matching 127.0.0.1 ? Something like: 127.0.0.1 machinename.domain.dom machinename localhost.localdomain localhost My guess is that localhost may be the first name matching 127.0.0.1 and fetchmail uses it in the helo. Frederic |
|
From: M. F. <mfi...@ne...> - 2007-08-16 16:12:55
|
On Thu, August 16, 2007 3:49 pm, Frederic Marchal wrote:
> According to fetchmail's man page smtpaddress adds the domain to the
> rcpt to, not to the helo of the envelope.
>
> Have a look at your /etc/hosts. Does the address 127.0.0.1 resolves
> first to the name of the machine or to localhost as is usually the case
> by default ?
>
> If localhost is the first name, could you rewrite /etc/hosts to put the
> machine name (what you want to see in the helo) as the first name
> matching 127.0.0.1 ? Something like:
>
> 127.0.0.1 machinename.domain.dom machinename localhost.localdomain
> localhost
>
> My guess is that localhost may be the first name matching 127.0.0.1 and
> fetchmail uses it in the helo.
>
Frederic,
thanks for your suggestion. /etc/hosts was indeed defaulting to localhost
and localhost.localdomain as the only values for 127.0.0.1
Changing it as you suggest _does_ (will it impact other services???):
127.0.0.1 machinename.domain.dom localhost localhost.localdomain
causes "hostname" to return "machinename.domain.dom". It is not enough,
however, to make fetchmail helo with that value, or so I understand:
################################################################
fetchmail: About to rewrite To: my_...@my...
Rewritten version is To: my_...@my...
fetchmail: SMTP< 220 machinename.domain.dom ESMTP Postfix
fetchmail: SMTP> EHLO localhost
fetchmail: SMTP< 250-machinename.domain.dom
fetchmail: SMTP< 250-PIPELINING
fetchmail: SMTP< 250-SIZE 10240000
fetchmail: SMTP< 250-ETRN
fetchmail: SMTP< 250-STARTTLS
fetchmail: SMTP< 250-ENHANCEDSTATUSCODES
fetchmail: SMTP< 250-8BITMIME
fetchmail: SMTP< 250 DSN
fetchmail: forwarding to localhost
fetchmail: SMTP> MAIL FROM:<a_t...@ya...> SIZE=1192
fetchmail: SMTP< 250 2.1.0 Ok
fetchmail: SMTP> RCPT TO:<mfi...@ne...>
fetchmail: SMTP< 504 5.5.2 <localhost>: Helo command rejected: need
fully-qualified hostname
fetchmail: SMTP error: 504 5.5.2 <localhost>: Helo command rejected: need
fully-qualified hostname
fetchmail: SMTP listener doesn't like recipient address
`mfi...@ne...'
##############################################################
having smtpaddress set or not in the fetchmailrc file doesn't change
anything. What now?
Thanks,
Marco
|
|
From: M. F. <mfi...@ne...> - 2007-08-16 16:30:11
|
Rob wrote: > Marco wrote: > > I take this to mean that setting smtpaddress as above isn't > > enough to not make fetchmail send an helo different than localhost.... > > Right, having taken a moment to dive into the code, the value > of the HELO/ELHO string that is presented is the value of smtphost. > This defaults to localhost - change this to the fully qualified name > of the host Unfortunately this doesn't seem enough. Doing a poll pop3.myisp.com with proto POP3 tracepolls user myaccount there with pass "thepassword" is mfi...@ne... here keep smtphost the.full.machine.name still yelds (may this depend on the fetchmail version???): fetchmail: About to rewrite To: mya...@my... Rewritten version is To: mya...@my... fetchmail: SMTP< 220 the.full.machine.name ESMTP Postfix fetchmail: SMTP> EHLO localhost fetchmail: SMTP< 250-the.full.machine.name fetchmail: SMTP< 250-PIPELINING fetchmail: SMTP< 250-SIZE 10240000 fetchmail: SMTP< 250-ETRN fetchmail: SMTP< 250-STARTTLS fetchmail: SMTP< 250-ENHANCEDSTATUSCODES fetchmail: SMTP< 250-8BITMIME fetchmail: SMTP< 250 DSN fetchmail: forwarding to the.full.machine.name fetchmail: SMTP> MAIL FROM:<a_test_address> SIZE=1192 fetchmail: SMTP< 250 2.1.0 Ok fetchmail: SMTP> RCPT TO:<mfi...@ne...> fetchmail: SMTP< 504 5.5.2 <localhost>: Helo command rejected: need fully-qualified hostname fetchmail: SMTP error: 504 5.5.2 <localhost>: Helo command rejected: need fully-qualified hostname fetchmail: SMTP listener doesn't like recipient address `mfi...@ne...' > Note that rejecting unqualified HELO values while being fully > RFC compliant... Yes, we're aware of this and in _our_ particular case we should be fine. For now, at least. > Which is why I went directly to the postfix site for that snippet, > and I don't even use postfix :) exactly my point. When the underlying terminology and standards are, shall we say, so peculiar, it doesn't matter much which server one uses, does it? Whereas having _already_ acquired_ over time an in-depth knowledge and understanding of the lingo helps a lot. This is where I hope to arrive, of course. Thanks for any further help! As a side note, I hope this thread continues until the problem is solved via fetchmail also because... I'm learning more about fetchmail this afternoon, thanks to this thread, than by reading the docs again and again... Marco |
|
From: Rob F. <rf...@fu...> - 2007-08-16 17:19:44
|
M. Fioretti wrote: > Rob wrote: > > Note that rejecting unqualified HELO values while being fully > > RFC compliant... > > Yes, we're aware of this and in _our_ particular case we should be > fine. For now, at least. Ideally in your smtpd restrictions you should tell postfix to permit_mynetworks *before* reject_non_fqdn_hostname and reject_invalid_hostname. And be sure mynetworks includes 127.0.0.0/8. > smtphost the.full.machine.name > > still yelds (may this depend on the fetchmail version???): > > fetchmail: SMTP> EHLO localhost I'm pretty sure this depends on the fetchmail version; a check of the NEWS file shows that there's been a lot of work on the smtphost feature since 6.2. OTOH the current man page doesn't seem to clearly talk about HELO/EHLO. -- ==============================| "A microscope locked in on one point Rob Funk <rf...@fu...> |Never sees what kind of room that it's in" http://www.funknet.net/rfunk | -- Chris Mars, "Stuck in Rewind" |
|
From: Rob M. <rob...@gm...> - 2007-08-16 17:26:06
|
On 8/16/07, M. Fioretti <mfi...@ne...> wrote: > > Unfortunately this doesn't seem enough. Doing a > > poll pop3.myisp.com with proto POP3 tracepolls > user myaccount there with pass "thepassword" is mfi...@ne... > here keep smtphost the.full.machine.name > > still yelds (may this depend on the fetchmail version???): I only have the source for 6.3.8 to hand. It's possible this feature is relatively recent. It may also be that there's something else happening to the value of the hostname beforehand - certainly lots of software relies on resolver libraries, which can be tripped up by having your hostname against the loopback address. I'd advise that, if you can, you create a second line with JUST the hostname in it, and the real IP of the host. Checking the source it looks like the hostname passed is based off of the value of id_me in sink.c. The value of that depends on whether "set invisible" is on (which I use). That may be set to the value of fetchmailhost, which defaults to localhost, but is later over-ridden by the DNS name of the host using gethostname. It may also default to value of server.truename, and I'm not enough of a C programmer to work out where that comes from :) However, an upgrade to 6.3.8 should at least confirm whether or not this is actually no longer a problem. > > Thanks for any further help! As a side note, I hope this thread continues > until the problem is solved via fetchmail also because... I'm learning > more about fetchmail this afternoon, thanks to this thread, than by > reading the docs again and again... As long as you're willing to put up my direct approach, I'm sure we'll get there :) -- Please keep list traffic on the list. Rob MacGregor Whoever fights monsters should see to it that in the process he doesn't become a monster. Friedrich Nietzsche |
|
From: Rob F. <rf...@fu...> - 2007-08-16 18:12:43
|
Rob MacGregor wrote: > I only have the source for 6.3.8 to hand. It's possible this feature > is relatively recent. See http://mknod.org/svn/fetchmail/ :-) Looks like the way fetchmailhost is determined (in fetchmail.c) has changed since 6.2.5. > It may also be that there's something else > happening to the value of the hostname beforehand - certainly lots of > software relies on resolver libraries, which can be tripped up by > having your hostname against the loopback address. > > I'd advise that, if you can, you create a second line with JUST the > hostname in it, and the real IP of the host. I agree. > Checking the source it looks like the hostname passed is based off of > the value of id_me in sink.c. The value of that depends on whether > "set invisible" is on (which I use). > > That may be set to the value of fetchmailhost, which defaults to > localhost, but is later over-ridden by the DNS name of the host using > gethostname. > > It may also default to value of server.truename, and I'm not enough of > a C programmer to work out where that comes from :) If invisible is on, fetchmail uses the POP/IMAP server's name for HELO. If invisible is off, fetchmail uses the pre-determined "fetchmailhost" value instead. fetchmailhost is determined by heuristics in fetchmail.c, and references the machine fetchmail is running on. It might be worthwhile to add an option to specify fetchmailhost in the config file. Not that I'll have time to do that anytime soon. -- ==============================| "A microscope locked in on one point Rob Funk <rf...@fu...> |Never sees what kind of room that it's in" http://www.funknet.net/rfunk | -- Chris Mars, "Stuck in Rewind" |
|
From: Rob M. <rob...@gm...> - 2007-08-16 19:44:30
|
On 8/16/07, Rob Funk <rf...@fu...> wrote:
>
> If invisible is on, fetchmail uses the POP/IMAP server's name for HELO.
> If invisible is off, fetchmail uses the pre-determined "fetchmailhost"
> value instead. fetchmailhost is determined by heuristics in fetchmail.c,
> and references the machine fetchmail is running on.
>
> It might be worthwhile to add an option to specify fetchmailhost in the
> config file. Not that I'll have time to do that anytime soon.
I'm of the opinion that a documentation change is all the should be
required, probably in the form of a FAQ entry. There must be very few
cases where what it's set to actually matters.
--
Please keep list traffic on the list.
Rob MacGregor
Whoever fights monsters should see to it that in the process he
doesn't become a monster. Friedrich Nietzsche
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X