Lep pozdrav
Imam registrirano domeno za spletno trgovino. Na serverju kjer se nahaja stran imam kreiran tudi mail, ki je info@moja_domena.net. Ta mail sem si nastavil tudi v outlook expressu, problem je, da če iz tega maila pošljem sporočilo na moj domači mejl, ki ga imam v uporabi pri t-2, dobim mail delivery failed response. To se zgodi samo, če pošljem na t-2 mail.
Pri 50webs, kjer gostujem pravijo, da je na njihovi strani vse v redu.
Kaj mi lahko svetujete?
še copy\paste sporočila, ki ga dobim, je pa editirano, da ne kažem svojga maila!
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
############@t-2.net
SMTP error from remote mail server after RCPT TO:<############@t-2.net>:
host smtp-bad-in-1.t-2.net [84.255.208.39]: 504 5.5.2 <50mail>:
Helo command rejected: need fully-qualified hostname
------ This is a copy of the message, including all the headers. ------
Return-path: <info@moja_domena.net>
Received: from [89.212.200.255] (helo=grega)
by 50mail with esmtpa (Exim 4.76)
(envelope-from <info@sesalec.net>)
id 1RDgBJ-0007v0-Vg
for #############@t-2.net; Tue, 11 Oct 2011 17:31:58 +0000
Message-ID: <33F42EF6A9A743B5AF97316421BC6E80@grega>
Reply-To: <info@moja_domena.net>
From: <info@moja_domena.net>
To: "Moje Ime" <############@t-2.net>
Subject: g
Date: Tue, 11 Oct 2011 19:31:29 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0005_01CC884C.5FA2F970"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109
This is a multi-part message in MIME format.
------=_NextPart_000_0005_01CC884C.5FA2F970
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
g
------=_NextPart_000_0005_01CC884C.5FA2F970
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META name=3DGENERATOR content=3D"MSHTML 8.00.6001.19120">
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000080 size=3D2 =
face=3DVerdana>g</FONT></DIV></BODY></HTML>
------=_NextPart_000_0005_01CC884C.5FA2F970--
Problem s sprejemom maila
-
MrTwelveTrees
- Moderator
- Prispevkov: 9137
- Pridružen: 1. Mar 2008 ob 21:14
- T-2: Že imam
- Paket: imam
Re: Problem s sprejemom maila
imam podobno kot ti, vendar meni e-mail ( moja@domena.com ) lavfa na gmailu. če poznaš -> Google Apps
imam samo dns server (mail forward -> gmail (Google Apps ))
in nimam nobenega problema
imam samo dns server (mail forward -> gmail (Google Apps ))
in nimam nobenega problema
-
NoName
- Administrator
- Prispevkov: 2091
- Pridružen: 16. Nov 2006 ob 20:26
- T-2: Že imam
- Paket: VDSL T4 KING + HDTV
Re: Problem s sprejemom maila
najbolje bi bilo, da bi skrbnik poštnega strežnika popravil samo konfiguracijo, da se bo le-ta predstavljal s polnim imenom (FQDN). če citiram http://tools.ietf.org/html/rfc5321
4.1.1.1. Extended HELLO (EHLO) or HELLO (HELO)
These commands are used to identify the SMTP client to the SMTP
server. The argument clause contains the fully-qualified domain name
of the SMTP client, if one is available. In situations in which the
SMTP client system does not have a meaningful domain name (e.g., when
its address is dynamically allocated and no reverse mapping record is
available), the client SHOULD send an address literal (see
Section 4.1.3).
RFC 2821, and some earlier informal practices, encouraged following
the literal by information that would help to identify the client
system. That convention was not widely supported, and many SMTP
servers considered it an error. In the interest of interoperability,
it is probably wise for servers to be prepared for this string to
occur, but SMTP clients SHOULD NOT send it.
The SMTP server identifies itself to the SMTP client in the
connection greeting reply and in the response to this command.
A client SMTP SHOULD start an SMTP session by issuing the EHLO
command. If the SMTP server supports the SMTP service extensions, it
will give a successful response, a failure response, or an error
response. If the SMTP server, in violation of this specification,
does not support any SMTP service extensions, it will generate an
error response. Older client SMTP systems MAY, as discussed above,
use HELO (as specified in RFC 821) instead of EHLO, and servers MUST
support the HELO command and reply properly to it. In any event, a
client MUST issue HELO or EHLO before starting a mail transaction.
These commands, and a "250 OK" reply to one of them, confirm that
both the SMTP client and the SMTP server are in the initial state,
that is, there is no transaction in progress and all state tables and
buffers are cleared.
Syntax:
ehlo = "EHLO" SP ( Domain / address-literal ) CRLF
helo = "HELO" SP Domain CRLF
Normally, the response to EHLO will be a multiline reply. Each line
of the response contains a keyword and, optionally, one or more
parameters. Following the normal syntax for multiline replies, these
keywords follow the code (250) and a hyphen for all but the last
line, and the code and a space for the last line. The syntax for a
positive response, using the ABNF notation and terminal symbols of
RFC 5234 [7], is:
ehlo-ok-rsp = ( "250" SP Domain [ SP ehlo-greet ] CRLF )
/ ( "250-" Domain [ SP ehlo-greet ] CRLF
*( "250-" ehlo-line CRLF )
"250" SP ehlo-line CRLF )
ehlo-greet = 1*(%d0-9 / %d11-12 / %d14-127)
; string of any characters other than CR or LF
ehlo-line = ehlo-keyword *( SP ehlo-param )
ehlo-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
; additional syntax of ehlo-params depends on
; ehlo-keyword
ehlo-param = 1*(%d33-126)
; any CHAR excluding <SP> and all
; control characters (US-ASCII 0-31 and 127
; inclusive)
Although EHLO keywords may be specified in upper, lower, or mixed
case, they MUST always be recognized and processed in a case-
insensitive manner. This is simply an extension of practices
specified in RFC 821 and Section 2.4.
The EHLO response MUST contain keywords (and associated parameters if
required) for all commands not listed as "required" in Section 4.5.1
excepting only private-use commands as described in Section 4.1.5.
Private-use commands MAY be listed.
4.1.1.1. Extended HELLO (EHLO) or HELLO (HELO)
These commands are used to identify the SMTP client to the SMTP
server. The argument clause contains the fully-qualified domain name
of the SMTP client, if one is available. In situations in which the
SMTP client system does not have a meaningful domain name (e.g., when
its address is dynamically allocated and no reverse mapping record is
available), the client SHOULD send an address literal (see
Section 4.1.3).
RFC 2821, and some earlier informal practices, encouraged following
the literal by information that would help to identify the client
system. That convention was not widely supported, and many SMTP
servers considered it an error. In the interest of interoperability,
it is probably wise for servers to be prepared for this string to
occur, but SMTP clients SHOULD NOT send it.
The SMTP server identifies itself to the SMTP client in the
connection greeting reply and in the response to this command.
A client SMTP SHOULD start an SMTP session by issuing the EHLO
command. If the SMTP server supports the SMTP service extensions, it
will give a successful response, a failure response, or an error
response. If the SMTP server, in violation of this specification,
does not support any SMTP service extensions, it will generate an
error response. Older client SMTP systems MAY, as discussed above,
use HELO (as specified in RFC 821) instead of EHLO, and servers MUST
support the HELO command and reply properly to it. In any event, a
client MUST issue HELO or EHLO before starting a mail transaction.
These commands, and a "250 OK" reply to one of them, confirm that
both the SMTP client and the SMTP server are in the initial state,
that is, there is no transaction in progress and all state tables and
buffers are cleared.
Syntax:
ehlo = "EHLO" SP ( Domain / address-literal ) CRLF
helo = "HELO" SP Domain CRLF
Normally, the response to EHLO will be a multiline reply. Each line
of the response contains a keyword and, optionally, one or more
parameters. Following the normal syntax for multiline replies, these
keywords follow the code (250) and a hyphen for all but the last
line, and the code and a space for the last line. The syntax for a
positive response, using the ABNF notation and terminal symbols of
RFC 5234 [7], is:
ehlo-ok-rsp = ( "250" SP Domain [ SP ehlo-greet ] CRLF )
/ ( "250-" Domain [ SP ehlo-greet ] CRLF
*( "250-" ehlo-line CRLF )
"250" SP ehlo-line CRLF )
ehlo-greet = 1*(%d0-9 / %d11-12 / %d14-127)
; string of any characters other than CR or LF
ehlo-line = ehlo-keyword *( SP ehlo-param )
ehlo-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
; additional syntax of ehlo-params depends on
; ehlo-keyword
ehlo-param = 1*(%d33-126)
; any CHAR excluding <SP> and all
; control characters (US-ASCII 0-31 and 127
; inclusive)
Although EHLO keywords may be specified in upper, lower, or mixed
case, they MUST always be recognized and processed in a case-
insensitive manner. This is simply an extension of practices
specified in RFC 821 and Section 2.4.
The EHLO response MUST contain keywords (and associated parameters if
required) for all commands not listed as "required" in Section 4.5.1
excepting only private-use commands as described in Section 4.1.5.
Private-use commands MAY be listed.
I can see dumb people...They're all around us... Look, they're even on this forum!
Re: Problem s sprejemom maila
zdravo
Se pravi, da napaka nikakor ni na strani T-2? Kaj točno naj bi na gostujočem strežniku morali popraviti. Naprimer, če pošljem na gmail ali pa na volja.net, sporočila prispejo normalno.
lp.
Se pravi, da napaka nikakor ni na strani T-2? Kaj točno naj bi na gostujočem strežniku morali popraviti. Naprimer, če pošljem na gmail ali pa na volja.net, sporočila prispejo normalno.
lp.
-
voyager2
- Guru
- Prispevkov: 999
- Pridružen: 9. Mar 2007 ob 17:59
- T-2: Že imam
- Paket: T4 300/100 Telekom GPON
- Kraj: Ljubljana
Re: Problem s sprejemom maila
Saj ti je NoName že napisal kaj morajo popraviti:
Tole jim pošlji pa naj uredijo.NoName napisal/-a:najbolje bi bilo, da bi skrbnik poštnega strežnika popravil samo konfiguracijo, da se bo le-ta predstavljal s polnim imenom (FQDN). če citiram http://tools.ietf.org/html/rfc5321
Re: Problem s sprejemom maila
Strežnik se predstavi kot "50mail" namesto s celotnim imenom (naprimer mail.50webs.com). V konfiguraciji programa Exim morajo nastaviti vrednost "primary_hostname".enigma77 napisal/-a:host smtp-bad-in-1.t-2.net [84.255.208.39]: 504 5.5.2 <50mail>:
Helo command rejected: need fully-qualified hostname
by 50mail with esmtpa (Exim 4.76)
Koda: Izberi vse
220 50mail ESMTP Exim 4.76Re: Problem s sprejemom maila
ok, hvala, jim bom javil
Kako to, da deluje, če pošljem na maile, ki niso od t-2?
Kako to, da deluje, če pošljem na maile, ki niso od t-2?
Re: Problem s sprejemom maila
Nimajo vsi mailerji vklopljenega tega preverjanja.
T-2 pač ima (anti spam funkcija) in zato blokira...
T-2 pač ima (anti spam funkcija) in zato blokira...