Last post DECLARING THREAD DEAD
there is no point arguing with the willful ignorant, they will drag you down to their level and beat you with experience.
either read/learn or ignore, but do not mis-educate others into adopting a HELO=MUST=FCRDNS policy as this is damaging to the efforts of all trying to espouse better sender practices, so that eventually receivers can determine {programatically} the good {well run} from the bad {badly run/and ratware}
it took us a long time to educate the world that open-relay was bad, were still working on accept-then-bounce {backscatter} but making headway {many small receivers still doing}, and were trying to get good senders to adopt useful-traceable-verifiable-as-MTA HELO/EHLO to make receivers filtering easier.
using HELO==FCRDNS {in your outgoing} dosn't make your sender bad but also dosn't elevate it above every piece of ratware, thus all mail MUST be subjected to same level of scrutiny from such senders.
requiring HELO==FCRDNS {in incomming} on the other hand will make the job of best practice senders more difficult, as people following your advice will reject the better senders. and only accept mail from those following this foolish policy and ratware{which already does}
At 10:03 09/03/2010 Tuesday, Alex van den Bogaerdt wrote:
>>there is no such thing as "official hostname" , the closest to that would
>>be the name configured on the box itself and returned by the $HOSTNAME
>>variable or hostname command
>
>And, as the HELO/EHLO command identifies the host, this is the name which
>should be used.
yes the hostname {which may be one of many A records pointed at the host}
not the FQRDNS {the specific hostname(s) used to identify the organization that is in control of the ip, verified {to defeat forgery} via doing a IP>PTR>A>IP verification chain
as the Organisation owning the A zone is frequently not the organisation administering the PTR thus verification is neccisary
>>as long as it has an A record it is fine in a HELO, using any hostname* is
>>legit vis a vis the RFC {as quoted above [and originally by you]}
>
>That text is to explain the difference between A and CNAME. It does not tell
>you that you can use any existing hostname or worse.
actually it does, it even specifically says that the HELO name pointing at ANY ip {not even the one used by the connecting client} is OK
we in the receiving community decided that we would strengthen this lax policy through SPF and CSV {to authenticate the HELO and limit the ips it would be accepted from}
HELOs without any stated policy {spf or csv} CAN be verified 'by does this point at the connecting ip' by reciever policy, but it would result in MANY false positives {all of face book for example}
verifying the helo further by tieing it to the same forward zone as the PTR is many receivers CHOICE {it definitely separates out the well setup from the rest} {and thus the ones likely to react to complaints if their users spam}
but mistakenly trying to force a policy requiring HELO to equal FCRDNS is NOT in the rfc's {whatever you may infer}
and is patently a really dumb idea
if better than RFC compliant behaviour is to be expected in HELO/EHLO then actually demand usefully better behaviour, not HELO==FCRDNS as every piece of malware/ratware already complies with this so it serves no purpouse other than to make life easier for ratware authors
>Following your line of reasoning, I would also be allowed to use your
>hostname... of course I am not.
you are {per the rfc's
you are not per my helo's stated CSV and SPF policy {one of my servers HELOs atm as bigsvr.alandoherty.net, its policy only allows this from its own ip, its ptr on the other hand has a deny spf and csv so even if ratware infested the host it could not successfully helo without parsing my exim config}
>>that is BULLSHIT!! plain and simple, its backward ass thinking and nothing to do with the rfc's
>
>Please make your point without using such language.
it would be easier if you did not continually state the ridiculous
>>>>{but the point is a hostname does not have to be the same hostname used
>>>>within the PTR,
>>>>and in these modern times SHOULD NOT BE
>>>
>>>Okay, I'm willing to agree with you here. What better information than
>>>RFC1035 do you have?
>>
>>simple experience of knowing that its programmatically impossible to
>>determine if a connection from a host in 99.99% of static ranges {ones
>>with a ptr allocated to businesses for the express intent of ensuring they
>>can run in-house mta's} originated with the MTA {good} or any random
>>desktop {BAD} if they follow the backward idea that their MTA should helo
>>with its FQRDNS name
>
>
>This is what the RFC, written in these modern times (oct 2008), has to say
>about it:
>
>"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).
>"
>
>What follows from this? A domain which does not have a reverse mapping is not a meaningful hostname and must not be used as HELO parameter.
you infer this, it is not what the document states
the document actually implys that if a client host talking [e]smtp
{and by that i do mean client as opposed to a MTA that is not allowed by any reciever to connect if it has no verifiable PTR {FCRDNS}}
has no method to determine its hostname [as it cannot lookup its PTR it not having one]{ie windows box that did not receive a dns name from AD/dhcp etc.} should helo as [its.ip.add.res] as opposed to a non qualified hostname such as mypc with no domain
some receivers choose to allow [xx.xx.xx.xx] address literals in direct to MX reception {most do not} no legit sender ever tries
>It is possible for a host to have more than one name which passes the A->PTR->same_A test.
there has never been such a test, no verification of A is necessary as the zone is under the control of the domain owner, only PTR's can and are regularly forged to imply that IP belongs to an organisations other than the real owner {thus the invention of IP>PTR>A>IP verification and the fact it is now used in all MTA's before a PTR is accepted/used/logged
> This could for instance happen on a multi homed host with different names for each interface. That does still not mean you can select any of those names.
actually you can have any number of PTRs on a single ip lookup any of hotmails sending IPs
its still pointless and dumb, but its easy to do, without needing to be multihomed
but back to your original example if a machine is multihomed {several ips, each with one unique PTR} {assuming the A's do not point at all the ips, just the one that the PTR is used for}
you cannot safely use any of them in a HELO
{both because FCRDNS should be avoided in HELO, and because you may connect out from an ip that doesn't match your HELO}
you should HELO as a hostname {within the same domain as the PTRs} that points to all the IPs, and thus can be A>IP verified and SPF / CSV verified also}
>The HELO parameter identifies the host. It does not identify the interface used, nor does it identify the organization as some seem to think.
the hostname contains a parent domain, thus it does identify an organization that has responsibility for the mail/abuse it sends.
> There's nothing wrong with using, say, www.openspf.org (provided that this is a name which resolves to an address which resolves back to the same name).
this is entirely untrue, woolly thinking and unsafe practice to promote
>>>Are you the same Alan that wrote:
>>>
>>>"www.microsoft.com is an alias thus has no A or MX and should be refused by all mailservers
>>>>>{crazily it points at microsoft.com and thus some dodgy libraries/mta's that follow aliases will allow user@www.micr.. and use the mx's from and spf from microsoft.com which I doubt they really wanted}"
>>
>>yes, its an alias thus SHOULD BE REFUSED as a HELO name which is what we are discussing
>
>If you were discussing HELO parameters, why did you choose an example of user@www.microsoft ?
as it was one of the domains listed by the original poster where a subdomain {guessable to exist} had a cname record so could be used to illustrate the point of where a HELO would be invalid {without looking for SPF or CSV}
he was asking about forgery of sub-domains where no SPF record is present, thus i was illustrating from his example list places where forgery of user@www and helo as www. would be valid/invalid and intended/unintended
ie www.openspf valid intended in both helo/user@ {probably unintended in user@}
www.microsoft invalid{as HELO}/unintended for both but passes SPF checks for both {thus DNS admin needs to brush up on Cnames and their unintended side effects}
>And what is dodgy about following aliases when trying to resolve mailbox domains?
nothing, and in my last followup {cut by you} i made this clear as you were choosing to read meaning into my less exacting original statement {requoted above} that was not there
{according to the RFCs} except that the owner of this domain did not intend it to be done, thus they didn't think about the implications of using a cname fully
my original restating of above in less re-interpretable language {for those insistent of reading unintended meanings into everything}
--------------------
yes, its an alias thus SHOULD BE REFUSED as a HELO name which is what we are discussing
and as it aliases to a domain with both A and MX records it would still be valid for user@www.microsoft {which their MX's do NOT accept thus is not what they intended}
and as some dodgy implementations of SPF libraries do follow cname-chains to txt/spf records and would therefore mistakenly allow in HELO and in envelope-from {which as i have mentioned was NOT their intent}
and as their microsoft.com spf ends in ~all would allow both unintended uses from everywhere
-------------------------------
>-------------------------------------------
>Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
>Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
>
>Archives: https://www.listbox.com/member/archive/1020/=now
>RSS Feed: https://www.listbox.com/member/archive/rss/1020/
>Powered by Listbox: http://www.listbox.com
-------------------------------------------
Sender Policy Framework:
http://www.openspf.org [
http://www.openspf.org]
Modify Your Subscription:
http://www.listbox.com/member/ [
http://www.listbox.com/member/]
Archives:
https://www.listbox.com/member/archive/1020/=now RSS Feed:
https://www.listbox.com/member/archive/rss/1020/ Powered by Listbox:
http://www.listbox.com