At 10:08 14/07/2009 Tuesday, Alessandro Vesely wrote:
Stuart D. Gathman wrote:
On Mon, 13 Jul 2009, Alex van den Bogaerdt wrote:
Even if the DNS in-addr.arpa entry points to that bigisp, which then points
back to the IP address, "v=spf1 a -all" will still validate an HELO parameter
like "smtp-out.example.com".
AFAIK, that will validate postmaster(_at_)smtp-out(_dot_)example(_dot_)com,
not user(_at_)example(_dot_)com unless example.com has an A record with the
same number.
the helo is validated by testing the for an spf for
postmaster(_at_)smtp-out(_dot_)example(_dot_)com
thats what SPF recommends already
also most isps just directly do a test of does A for helo resolve to ip of
connected host at helo time
(In that case it could have just said "HELO example.com".)
if you did you would be entirely missing the point of helo and failing test 2
{here all mail gets a special X-DUMB-ADMIN: header with details for these sorts
of helo errors, and most users filter mail with theses errors to spam as 99% of
mail from dumbly administered systems tends to be spam {as they are least
likely to catch compromises and spamming users}
I am talking about using the name provided by HELO to validate a MAIL FROM
identity - not the HELO identity.
that would just be dumb as a brick
few MTA's would ever be used by a single domain only
even small business MTA's tend to receive/send for company-name.com
companyname.com company-name.co.uk etc.
and most will send out {smtp-auth server provided by isp} relay.their-isp.com
no relationship between helo and envelope-sender can or should be implied or
inferred
if one is ever implied or inferred you will just get silly idiots setting up a
different helo per outgoing envelope-sender
{easy for spambots impossible on most legit MTA's}
so you would be setting up a new "standard" thats easier for spam to comply
with than legit mailers
{the standard ATM is fine
setup an SPF for each Envelope-Sender that references the sending MTA's ips
setup an SPF for each HELO/EHLO identity that references that MTA's ips only
setup an SPF for each other domain that referances no ips v=spf1 -all to block
forgery in either helo or envelope-sender of these
{such as www.example.org pop3.example.org ftp.example.org and any others
non spf but "standard" dns admin stuff
setup an A for helo/ehlo identity that points to the ips of that server {for
non-spf helo checkers}
setup an A for top-level domain pointing at a server that is on the MX list for
top-level domain
{to get mail from dumb mta's that still use A before MX}
setup a http server on same server pointed to above to 301 re-direct traffic to
http://top-level domain correctly to http://www.top-level domain
{nothing to do with mail but reason why so many point both top-level and
www.top-level at their webhost and choose to ignore mail from broken A before
MX hosts entirely, the above workaround is better from a lossless and SEO
perspective, and for those of us old enough to remember its the reason why we
ever standardised on www.domain for webhosts so we could continue to point
domain at MTS's}
also for all non-envelope and non-receiver domains publish MX 0 .
so any mta see's no valid MX's thus shouldn't assume still valid using fallback
to A {as mx's exist thus no fallback to A ever}
{as another "works with non SPF checking receivers" anti forgery system}
also standard setup a ptr for each host ip pointing to a name in your domain
{best if the name is unique for ptr use not mail.xx www.xx or other in-use
name} setup and point those names back to those same ip's and setup v=spf1 -all
and MX 0 . records for all these
{so bot infections which can easily determine their ptr name cannot still
determine a valid helo or if default heloing as ptr can easily be rejected by
recievers}
Would "a:%{h2}" do the trick here?
That was the reason I wondered about an equality relationship. Say smtp-out is
delivering two messages, one from user(_at_)example(_dot_)com and one from
user(_at_)example(_dot_)ORG, a virtual domain. Both messages are delivered
during the same session, but %{h2} is example.com, not .ORG.
I would say that example.com ~ example.ORG iff they share at least one primary
MX. Such relationship would be reflexive and symmetric, but not necessarily
transitive. In addition, it apparently confuses smtp-out and smtp-in.
-------------------------------------------
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
-------------------------------------------
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