Author
S: 220 smtp.example.com ESMTP Postfix
C: HELO relay.example.org
S: 250 Hello relay.example.org, I am glad to meet you
C: MAIL FROM:<bob@example.org>
S: 250 Ok
C: RCPT TO:<alice@example.com>
S: 250 Ok
C: RCPT TO:<theboss@example.com>
S: 250 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: From: "Bob Example" <bob@example.org>
C: To: Alice Example <alice@example.com>
C: Cc: theboss@example.com
C: Date: Tue, 15 Jan 2008 16:02:43 -0500
C: Subject: Test message
C:
C: Hello Alice.
C: This is a test message with 5 headers and 4 lines in the body.
C: Your friend,
C: Bob
C: .
S: 250 Ok: queued as 12345
C: QUIT
S: 221 Bye
{The server closes the connection}
this is a conversation between server avd clinet communication by smtp
i wanna know what is the significance of the string written after HELO
that is what does relay.example.org represents
if i from my home wants to use smtp , what iam supposed to write in place of relay.example.org ?
thanks in advance
Quote:Original post by iamspecialIt doesn't mean anything really, the only thing I've seen it used for is logging purposes. RFC 821 says:
this is a conversation between server avd clinet communication by smtp
i wanna know what is the significance of the string written after HELO
that is what does relay.example.org represents
if i from my home wants to use smtp , what iam supposed to write in place of relay.example.org ?
thanks in advance
Quote:HELLO (HELO)
This command is used to identify the sender-SMTP to the
receiver-SMTP. The argument field contains the host name of
the sender-SMTP.
The receiver-SMTP identifies itself to the sender-SMTP in
the connection greeting reply, and in the response to this
command.
This command and an OK reply to it confirm that both the
sender-SMTP and the receiver-SMTP are in the initial state,
that is, there is no transaction in progress and all state
tables and buffers are cleared.
Also, if you're sending mail from your own machine, you should be relaying it to your ISP, a lot of mail servers won't accept mail from just anyone.
Author
Quote:Original post by Evil Steve
Also, if you're sending mail from your own machine, you should be relaying it to your ISP, a lot of mail servers won't accept mail from just anyone.
does that mean that i have to use this
helo (my isp server name )
and then it will be ok
Quote:Original post by iamspecialNo, you need to connect to your ISPs mail server rather than directly to, say mail.google.com or whatever. Your ISP will then relay the mail to the target server for you. You might be doing this already of course. When you're connected to your ISPs mail server, it won't really matter what you put after "HELO".Quote:Original post by Evil Steve
Also, if you're sending mail from your own machine, you should be relaying it to your ISP, a lot of mail servers won't accept mail from just anyone.
does that mean that i have to use this
helo (my isp server name )
and then it will be ok
The string after the HELO (or EHLO) is the name that the connecting server (i e, you) think you have.
The relaying rules are typically something like:
1) Is the user authenticated as one of my trusted users?
-> allow relay
2) Is the incoming mail address destined for one of my users?
-> allow receipt
3) Else give up and disallow relay
Many servers add additional tests, such as "is the sender IP on a list of known spammers" or "does there exist a proper reverse DNS for the sender IP." There's also the SPF (sender policy framework) record.
Note that many mail servers have the entire Comcast client network marked as "known spammers," so don't try running a mail server on a cable modem. I have, however, run a mail serer over proper DSL (with proper reverse DNS) for a long time, and it's worked fine.
Except the spam traffic started becoming so heavy that my dual-core Core 2 6550 with 4 GB of RAM couldn't keep up, and it was saturating my downlink constantly with just spam, even when checking reverse DNS, RBL and SPF records. At that point, I decided to give up and moved my mail hosting to google apps :-/
It was fun while it lasted, though (like, for the last 10 years!)
The relaying rules are typically something like:
1) Is the user authenticated as one of my trusted users?
-> allow relay
2) Is the incoming mail address destined for one of my users?
-> allow receipt
3) Else give up and disallow relay
Many servers add additional tests, such as "is the sender IP on a list of known spammers" or "does there exist a proper reverse DNS for the sender IP." There's also the SPF (sender policy framework) record.
Note that many mail servers have the entire Comcast client network marked as "known spammers," so don't try running a mail server on a cable modem. I have, however, run a mail serer over proper DSL (with proper reverse DNS) for a long time, and it's worked fine.
Except the spam traffic started becoming so heavy that my dual-core Core 2 6550 with 4 GB of RAM couldn't keep up, and it was saturating my downlink constantly with just spam, even when checking reverse DNS, RBL and SPF records. At that point, I decided to give up and moved my mail hosting to google apps :-/
It was fun while it lasted, though (like, for the last 10 years!)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
