spf-discuss
[Top] [All Lists]

RE: Re[11]: [spf-discuss] Trying to understand the best recommendation for my client, help appreciated.

2009-05-13 19:02:12
At 22:57 13/05/2009  Wednesday, Mark wrote:
-----Original Message-----
From: alan [mailto:spfdiscuss(_at_)alandoherty(_dot_)net] 
Sent: woensdag 13 mei 2009 20:08
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re[10]: [spf-discuss] Trying to understand the best recommendation
for my client, help appreciated.

... just one word of advice don't be like 90% of MTA admins and
completely disregard the mandatory need for SPF for your EHLO/HELO
greeting ID.

They've probably been disregarding it, because there is NO such mandatory
need. From RFC 4408:

2.1.  The HELO Identity

  It is RECOMMENDED that SPF clients not only check the "MAIL FROM"
  identity, but also separately check the "HELO" identity by applying
  the check_host() function (Section 4) to the "HELO" identity as the
  <sender>.

if you do you will seem to any of us compliance extremists just to be
another spambot as no other SPF checks are considered trusted if HELO/EHLO
doesn't pass.

That's an utterly ignorant statement. For all the (loud) grandstanding
you've been doing for the last few days, perhaps you ought to do well and
get your own affairs in order first.

in deference to your quoting only the part referencing what the client is 
recommended to check {reciever side}

and because my own domains and MTA's do publish the correct SPF 
and on a per user address basis too ie nosuchuser(_at_)anyofmydomains will 
return an spf of "v=spf1 -all"

heres the relevant parts bolding of parts that make HElO publising manditory
{manditory for all {except but servers that never send mail from <>, ie servers 
that never send NDR's} which are few and far between}

2.2.  The MAIL FROM Identity

   The "MAIL FROM" identity derives from the SMTP MAIL command (see
   [RFC2821]).  This command supplies the "reverse-path" for a message,
   which generally consists of the sender mailbox, and is the mailbox to
   which notification messages are to be sent if there are problems
   delivering the message.

   [RFC2821] allows the reverse-path to be null (see Section 4.5.5 in
   RFC 2821).  In this case, there is no explicit sender mailbox, and
   such a message can be assumed to be a notification message from the
   mail system itself.  When the reverse-path is null, this document
   defines the "MAIL FROM" identity to be the mailbox composed of the
   localpart "postmaster" and the "HELO" identity (which may or may not
   have been checked separately before).

   SPF clients MUST check the "MAIL FROM" identity.  SPF clients check
   the "MAIL FROM" identity by applying the check_host() function to the
   "MAIL FROM" identity as the <sender>.

2.3.  Publishing Authorization

   An SPF-compliant domain MUST publish a valid SPF record as described
   in Section 3.  This record authorizes the use of the domain name in
   the "HELO" and "MAIL FROM" identities by the MTAs it specifies.

   If domain owners choose to publish SPF records, it is RECOMMENDED
   that they end in "-all", or redirect to other records that do, so
   that a definitive determination of authorization can be made 



-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com

<Prev in Thread] Current Thread [Next in Thread>