Re: For those following Sender based authentication - a question

2004-11-22 Thread Dan Jenkins
Benjamin Scott wrote:
Sheesh.  HELO is not a header.  :-)  RFC-2821, Section 4.1.1.1,
Paragraph 3, further states:
... In any event, a client MUST issue HELO or EHLO before starting a 
mail transaction.

Any questions?  :-)
None now, sir. :-)
I did a little research and realized that the reason various mail
servers allowed email without HELO was because of broken mail servers
(apparently, WinNT had one - surprise, surprise). And Daniel Borstein
(of qmail fame) felt HELO/EHLO was obsolete. I never went back to the
RFCs like I should have. Thanks for the definitive clarification.
--
Dan Jenkins ([EMAIL PROTECTED])
Rastech Inc., Bedford, NH, USA --- 1-603-206-9951
*** Technical Support for over a Quarter Century
___
gnhlug-discuss mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss


Re: For those following Sender based authentication - a question

2004-11-22 Thread Benjamin Scott

  Sheesh.  HELO is not a header.  :-)

  I quote from RFC-821, Section 4.1.1, Page 19:

 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.

  Particuarly relivant are "This command is used to identify the sender-SMTP
to the receiver-SMTP" (i.e., identifies the client to the server), and
"there is no transaction in progress" (i.e., no message is currently being
transferred).

  RFC-2821, Section 4.1.1.1, Paragraph 3, further states:

... In any event, a client MUST issue HELO or EHLO before starting a
mail transaction.

  Any questions?  :-)

-- 
Ben Scott <[EMAIL PROTECTED]>
| The opinions expressed in this message are those of the author and do  |
| not represent the views or policy of any other person or organization. |
| All information is provided without warranty of any kind.  |



___
gnhlug-discuss mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss


Re: For those following Sender based authentication - a question

2004-11-22 Thread Benjamin Scott
On Sun, 21 Nov 2004, at 10:08pm, [EMAIL PROTECTED] wrote:
> The HELO domain represents the mail provider used by the author of the
> message and thus is more closely related to the author than any other
> header within the message.

  Eh...

  HELO isn't even a header.  It is an SMTP command verb.  One might be able
to deduce the HELO information from a "Received" header, but I wouldn't bet
on it.

  HELO is issued by the sender-SMTP (AKA client) to identify itself to the
receiver-SMTP (AKA server AKA listener).  All it does is identify the client
for the duration of an SMTP session.  It has *nothing* to do with the mail
being transferred.  Indeed, you can issue a HELO without ever sending a
message, and you can deliver multiple messages in a single SMTP session (all
on the same HELO).

  And, like the rest of Internet email, none of this is authenticated by
default.  The HELO information and the "Received" header are frequently
forged.  HELO doesn't even permit authentication (you need EHLO, to identify
yourself as ESMTP capable, for that).  The HELO information is also
frequently wrong though misconfiguration -- many hosts (especially end-user
submitters) don't even know their own host name.

  Somebody is really far off base here.  :-)

> This is from the CSV doc to the FTC.

  Huh?  "CSV doc to the FTC"?  In my world, FTC is "Federal Trade
Commission", and CSV is "Comma Separated Value".  Given those expansions, I
cannot understand the above sentence.  Please restate it more clearly.

  :-)

-- 
Ben Scott <[EMAIL PROTECTED]>
| The opinions expressed in this message are those of the author and do  |
| not represent the views or policy of any other person or organization. |
| All information is provided without warranty of any kind.  |

___
gnhlug-discuss mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss


Re: For those following Sender based authentication - a question

2004-11-21 Thread Dan Jenkins
Jeff Macdonald wrote:
On Sun, 21 Nov 2004 23:18:20 -0500, Dan Jenkins wrote:
I was a bit too quick on the reply, the HELO in the mail header is from
the first mail server which accepts the message. Subsequent hops don't
change the initial HELO.

I must re-read the RFCs. I was not under the impression this was so.
I was not clear, correct or coherent. (And it is late and I ought not to 
be replying now, but getting some sleep. ;-) Having said that, I'll try 
one more time. :-)

You are correct. A HELO is usually done at each mail server along the 
way. It is not required in the protocol AFAIK (you can disable the 
requirement for a HELO in some mail servers), but all the mail servers 
I've dealt with require a HELO. So, even if not required by the RFC, it 
is nowadays a de facto standard.

In any event, the mail servers record the HELO (if any) and the IP# of 
each hop in the message headers. Some mail servers actually do include 
the phrase "HELO" in the headers, not all do. (I think it is Sendmail 
which does.)

Of course, the mail headers can be rewritten by any mail server along 
the way. I've done so in special cases. The initial HELO to the mail 
server is often incorrect. (I've stopped trying to use it for spam 
reduction, because legitimate mail servers so frequently had bogus HELOs.)

Thanks for posting the link to the material:
http://www.csvmail.org/email-authentication-summit-comments-P044411.pdf
They are talking about amending the RFC to require authenticated HELO.
I'll have to think on this. (And not react so fast.)
It is interesting.
--
Dan Jenkins ([EMAIL PROTECTED])
Rastech Inc., Bedford, NH, USA --- 1-603-206-9951
*** Technical Support for over a Quarter Century
___
gnhlug-discuss mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss


Re: For those following Sender based authentication - a question

2004-11-21 Thread Jeff Macdonald
On Sun, 21 Nov 2004 23:18:20 -0500, Dan Jenkins wrote:
> I was a bit too quick on the reply, the HELO in the mail header is from
> the first mail server which accepts the message. Subsequent hops don't
> change the initial HELO.

I must re-read the RFCs. I was not under the impression this was so.

-- 
Jeff Macdonald
Ayer, MA
___
gnhlug-discuss mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss


Re: For those following Sender based authentication - a question

2004-11-21 Thread Dan Jenkins
I was a bit too quick on the reply, the HELO in the mail header is from 
the first mail server which accepts the message. Subsequent hops don't 
change the initial HELO. However,  I do have mail servers which have to 
rewrite headers and provide a specific domain in a HELO for mail to be 
accepted. (A certain ISP requires this.) Some of my mail relays write 
the headers after cleaning up messages and then send them to internal 
mail servers. They show a fresh HELO from the gateway mail server. And, 
as someone mentioned, HELO is frequently (usually?) wrong. One (all?) of 
the Outlook clients do not send a valid HELO in any event (they don't 
use a FQDN and just use the system name). The HELO does include the IP 
number of the sender (presuming it hasn't been rewritten along the way), 
so, perhaps that is what the FTC was intending - ignore the HELO name 
and presume the HELO IP# to be the author. It still doesn't work, but it 
is not as unreasonable as my first knee jerk reaction was.

--
Dan Jenkins ([EMAIL PROTECTED])
Rastech Inc., Bedford, NH, USA --- 1-603-206-9951
*** Technical Support for over a Quarter Century
___
gnhlug-discuss mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss


Re: For those following Sender based authentication - a question

2004-11-21 Thread Jason Stephenson
Jeff Macdonald wrote:
Anybody agree with the following statement?
The HELO domain represents the mail provider used by the author of the
message and thus is more closely related to the author than any other
header within the message.
This is from the CSV doc to the FTC. Is is just mean, or does this
seem to ignore multiple hops?
I disagree with that statement completely, because the HELO can be and 
often is any-old string the spammer, errr, the author of the message 
feels like putting in there. You'd be surprised at the number of 
connections that my mail servers reject from other servers that send 
either my server's IP number or host name as their name in the HELO.

___
gnhlug-discuss mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss


Re: For those following Sender based authentication - a question

2004-11-21 Thread Dan Jenkins
Jeff Macdonald wrote:
Anybody agree with the following statement?
The HELO domain represents the mail provider used by the author of the
message and thus is more closely related to the author than any other
header within the message.
This is from the CSV doc to the FTC. Is is just mean, or does this
seem to ignore multiple hops?
HELO (or EHLO) is just the LAST machine to deliver the message. It
doesn't have to be close to the author whatsoever. For example, I have
systems which deliver their own email, except to certain domains, in
which case they use another SMTP server. So, the HELO is sometimes x.y.z
and other times a.b.c.
I have machines that relay mail from the outside world to internal mail
servers - and vice versa. If you look at our in-house mail server, ALL
messages begin with EHLO office.rastech.com.
If that's what the FTC is basing stuff on, someone ought to educate them
quickly.
--
Dan Jenkins ([EMAIL PROTECTED])
Rastech Inc., Bedford, NH, USA --- 1-603-206-9951
*** Technical Support for over a Quarter Century
___
gnhlug-discuss mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss