Mailing List Archive

At 21:52 10/07/2009 Friday, Stuart D. Gathman wrote:
>In my "best-guess" algorithm, a validated HELO (that resolves to the connect ip)
>is added to the collection of validated PTR records for the PTR mechanism.
>
>I propose to make this a MUST behaviour for spfv3. Many small businesses
>on DSL or Cable internet find it difficult to get their ISP to maintain
>PTR records. The HELO name in an SMTP connection serves the same purpose
>as a PTR record, and is already available. PTR lookups are a waste
>of bandwidth (for authentication purposes) when HELO is available and valid.
>While SPF macros can select the rightmost parts of HELO, and it is
>possible for SPF to verify that HELO matches the connect ip (somewhat
>kludgily), I haven't hit on a way to check that the rightmost parts
>of HELO match the MAILFROM domain using spfv1.
>
>A literal compare operation added to spfv3 could serve the same purpose,
>but I don't have any concrete syntax proposals.

untrue:
example if a spammer has a bot infecting my home pc
ptr host244.freudenhaus.alandoherty.net
he can quite happily connect to you and helo as mail.spammersdomain.com
and have ensured that mail.spammersdomain.com points at my ip {and possibly 100 others, ok 5 }
thus passing your test but proving nothing of his authenticity {as we know the ip is mine not his}

the checking of ptr > name > ip
is a method of validating the ip's identity not the helo or the spf records

its entirely independent of spf and even isps refusing to check spf use it
[to either score or reject badly setup MTAs mail]

as far as spf is concerned ptr is unused unless the spf policy of the helo or envelope-sender asks for it to be used

thus same spammer sending from blah@spammersotherdomain.com
as long as he has an spf of "v=spf1 A:mail.spammersdomain.com A:mail2.spammersdomain.com A:mail3.spammersdomain.com -ALL"
on spammersotherdomain.com
and has an spf for mail{x}.spammersdomain.com of "v=spf1 A -ALL"

he has already passed all the most rigorous of spf checks
and ensures each of his helo names points to a cluster of bots and each bot in the cluster will helo with the right name

SPF is about authorising your IP's to send mail for your domains
you can already authorize ips you have no ptr setup for in your spf

receivers that refuse mail from servers with no ptr / broken ptr are not doing this due to spf they do this due to common sense and will not change that anytime soon {this predates spf by many years and more dumb isp's are unlikely to change this}

interestingly the theoretical bot herder in this case would get through both as my ptr will also pass ptr check {it dosn't have to be same name as helo}

{all sensible receivers will also whitelist servers from ptr checks if known to be legit and useless isp involved, i have many such whitelistings for MTA's I know are good despite being broken}





-------------------------------------------
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

On Fri, 10 Jul 2009, alan wrote:
> [ In response to Stuart D. Gathman's proposal ]
> untrue:
> example if a spammer has a bot infecting my home pc
> ptr host244.freudenhaus.alandoherty.net

Re-read Stuart's message. He is not proposing that reverse-DNS consistency,
and checks for "dialup looking" hostnames, be overridden by a HELO.

Rather, he's just asking for a new mechanism, which is similar to ptr, but
uses the HELO rather than a reverse-DNS check. Both mechanisms do a
forward-check afterwards, so they are equally unforgeable.

And the new mechanism would only affect the SPF checks of domains that use
it.

We don't need to worry about hostile parties using it in SPF records they
control. They don't need it -- they can get all they want (an SPF record
that is effectively +all without being programmatically detectable as same)
using the exists mechanism.

---- Michael Deutschmann <michael@talamasca.ocis.net>


-------------------------------------------
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

alan wrote:
> At 21:52 10/07/2009 Friday, Stuart D. Gathman wrote:
>>In my "best-guess" algorithm, a validated HELO (that resolves to the connect ip)
>>is added to the collection of validated PTR records for the PTR mechanism.
>>
>>I propose to make this a MUST behaviour for spfv3.

To check if I understood, assume the client said

HELO mta.example.com
MAIL FROM:<me@example.com>

Now, if rDNS is correct, "ptr:%{h}" matches. If rDNS is not set up,
but you add the helo name, it obviously matches. The ptr mechanism
checks that each lhs _ends in_ the rhs, a somewhat crude form on DNS
names relationship.

>>While SPF macros can select the rightmost parts of HELO, and it is
>>possible for SPF to verify that HELO matches the connect ip (somewhat
>>kludgily), I haven't hit on a way to check that the rightmost parts
>>of HELO match the MAILFROM domain using spfv1.

I have some doubts about the meaning one can derive from that, in
particular for virtual domains. In general, one cannot deduce
administrative relationships: mta.example.com may be unrelated to
example.com, just like the latter is unrelated to .com.

>>A literal compare operation added to spfv3 could serve the same purpose,
>>but I don't have any concrete syntax proposals.

If helo name addition were mandatory or rDNS correct, ptr:%{o} would
match in some cases. We could add a "ptrhelo" mechanism to mean ptr +
helo, and/or a "helo" one to mean only the added helo name. Thus,
helo:%{h} would be a tautology. Is that (sort of) what you meant?

> the checking of ptr > name > ip
> is a method of validating the ip's identity not the helo or the spf records

It has been standardized as The "iprev" Authentication Method in
http://tools.ietf.org/html/rfc5451#section-3



-------------------------------------------
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

(resent from subscribed address)

----- Original Message -----
From: "Stuart D. Gathman" <stuart@bmsi.com>
To: <spf-discuss@v2.listbox.com>
Sent: Friday, July 10, 2009 10:52 PM
Subject: [spf-discuss] Feature request for SPFv3


> In my "best-guess" algorithm, a validated HELO (that resolves to the
> connect ip)
> is added to the collection of validated PTR records for the PTR mechanism.
>
> I propose to make this a MUST behaviour for spfv3.

It seems a newline is needed here. Your next line talks about HELO which
cannot be validated.

> Many small businesses
> on DSL or Cable internet find it difficult to get their ISP to maintain
> PTR records. The HELO name in an SMTP connection serves the same purpose
> as a PTR record, and is already available. PTR lookups are a waste
> of bandwidth (for authentication purposes) when HELO is available and
> valid.

Here you mean DNS PTR lookups, not the SPF ptr mechanism, right?

> While SPF macros can select the rightmost parts of HELO,

Why would one do this?

> and it is
> possible for SPF to verify that HELO matches the connect ip (somewhat
> kludgily),

Am I missing something? You seem to be describing the following:

If the MTA is hostname.example.com with ip 10.1.2.3, if DNS does not know
"3.2.1.10.in-addr.arpa PTR hostname.example.com" but there is
"hostname.example.com A 10.1.2.3", then "v=spf1 a -all" is all what's
needed.

> I haven't hit on a way to check that the rightmost parts
> of HELO match the MAILFROM domain using spfv1.

The ptr mechanism, which should be abandoned IMHO, does this. But indeed
that needs a properly setup DNS. It seems that you propose something like
"heloptr" which would use the HELO parameter instead of what is found in the
in-addr.arpa part of the DNS tree. Those who are unable or unwilling to
setup DNS correctly, won't understand that "heloptr" would also match
dyn-10-1-2-3.customer.example.com. This may or may not be harmful, but is
probably not what was intended.

> A literal compare operation added to spfv3 could serve the same purpose,
> but I don't have any concrete syntax proposals.




-------------------------------------------
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

On Sat, 11 Jul 2009, Alex van den Bogaerdt wrote:

> > In my "best-guess" algorithm, a validated HELO (that resolves to the
> > connect ip)
> > is added to the collection of validated PTR records for the PTR mechanism.
> >
> > I propose to make this a MUST behaviour for spfv3.
>
> It seems a newline is needed here. Your next line talks about HELO which
> cannot be validated.

HELO is "validated" in the same way a PTR record is - by checking for
a match with connect ip.

> > as a PTR record, and is already available. PTR lookups are a waste
> > of bandwidth (for authentication purposes) when HELO is available and
> > valid.
>
> Here you mean DNS PTR lookups, not the SPF ptr mechanism, right?

I mean the DNS PTR lookups caused by the SPF ptr mechanism.

> > While SPF macros can select the rightmost parts of HELO,
>
> Why would one do this?

To match it to the mail domain like with the SPF ptr mechanism.

> > and it is
> > possible for SPF to verify that HELO matches the connect ip (somewhat
> > kludgily),
>
> Am I missing something? You seem to be describing the following:

You are missing something. Think of HELO as a PTR record that is
supplied via SMTP instead of a DNS lookup.

> > I haven't hit on a way to check that the rightmost parts
> > of HELO match the MAILFROM domain using spfv1.
>
> The ptr mechanism, which should be abandoned IMHO, does this. But indeed
> that needs a properly setup DNS. It seems that you propose something like
> "heloptr" which would use the HELO parameter instead of what is found in the
> in-addr.arpa part of the DNS tree. Those who are unable or unwilling to
> setup DNS correctly, won't understand that "heloptr" would also match
> dyn-10-1-2-3.customer.example.com. This may or may not be harmful, but is
> probably not what was intended.

It is what was intended. When example.com contracts with bigisp.com to
provide a dsl account with a small static IP block (typically /29), the problem
is that bigisp.com is typically unable to reliably provide PTR records
chosen by example.com[*]. However, the PTR record they do chose will
be something like 'dyn-10-1-2-3.bigisp.com', *not* 'dyn-10-1-2-3.example.com',
(never mind that the contract is for static ips).

Bigisp.com should simply not use the PTR mechanism for an SPF policy.

> > A literal compare operation added to spfv3 could serve the same purpose,
> > but I don't have any concrete syntax proposals.

[*]The most egregious example is bellsouth, who happily charges you for
static IPs, but then reports those static IPs to the DUL.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.


-------------------------------------------
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

On Sat, 11 Jul 2009, Alessandro Vesely wrote:

> If helo name addition were mandatory or rDNS correct, ptr:%{o} would match in
> some cases. We could add a "ptrhelo" mechanism to mean ptr + helo, and/or a
> "helo" one to mean only the added helo name. Thus, helo:%{h} would be a
> tautology. Is that (sort of) what you meant?

Yes. A separate helo mechanism would probably be cleaner. I only
proposed adding it to ptr because HELO effectively acks as a PTR record
delivered via SMTP instead of DNS.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.


-------------------------------------------
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

On Fri, 10 Jul 2009, alan wrote:

> At 21:52 10/07/2009 Friday, Stuart D. Gathman wrote:
> >In my "best-guess" algorithm, a validated HELO (that resolves to the connect ip)
> >is added to the collection of validated PTR records for the PTR mechanism.
> >
>
> untrue:
> example if a spammer has a bot infecting my home pc
> ptr host244.freudenhaus.alandoherty.net
> he can quite happily connect to you and helo as mail.spammersdomain.com
> and have ensured that mail.spammersdomain.com points at my ip {and possibly 100 others, ok 5 }
> thus passing your test but proving nothing of his authenticity {as we know the ip is mine not his}

You wouldn't put ptr:spammersdomain.com in your SPF policy (would you?).

It proves that the email was controlled by spammersdomain.com, and
that is the domain that gets blacklisted, not alandoherty.net.

> the checking of ptr > name > ip
> is a method of validating the ip's identity not the helo or the spf records

HELO > name > ip validates helo.

> you can already authorize ips you have no ptr setup for in your spf

That is a fair point: probably strong enough to withdraw the proposal.
Since you (the sender) control the HELO, you can always provide a A mechanism
instead for an SPF policy.

The enhanced PTR (or HELO) mechanism is only really useful in
best-guess algorithms. I was just hoping to help standardize guessing a
little.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.


-------------------------------------------
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

----- Original Message -----
From: "Stuart D. Gathman" <stuart@bmsi.com>
To: <spf-discuss@v2.listbox.com>
Sent: Monday, July 13, 2009 6:34 PM
Subject: Re: [spf-discuss] Feature request for SPFv3


> On Sat, 11 Jul 2009, Alex van den Bogaerdt wrote:
>
>> > In my "best-guess" algorithm, a validated HELO (that resolves to the
>> > connect ip)
>> > is added to the collection of validated PTR records for the PTR
>> > mechanism.
>> >
>> > I propose to make this a MUST behaviour for spfv3.
>>
>> It seems a newline is needed here. Your next line talks about HELO which
>> cannot be validated.
>
> HELO is "validated" in the same way a PTR record is - by checking for
> a match with connect ip.

My point is: either DNS is setup correctly, PTR records are setup, or it
isn't. "... find it difficult to get their ISP to maintain PTR records."
seems to indicate that DNS is not setup correctly.

Anyway, this does not seem to be important, read on.



>> > While SPF macros can select the rightmost parts of HELO,
>>
>> Why would one do this?
>
> To match it to the mail domain like with the SPF ptr mechanism.

???

AFAIK the ptr mechanism does not tie helo to the mail domain.

>> > and it is
>> > possible for SPF to verify that HELO matches the connect ip (somewhat
>> > kludgily),
>>
>> Am I missing something? You seem to be describing the following:

[deleted by stuart: v=spf a -all]

> You are missing something. Think of HELO as a PTR record that is
> supplied via SMTP instead of a DNS lookup.

Verifying that the connected IP and the HELO parameter match, is done using
the "a" mechanism.

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".

>> > I haven't hit on a way to check that the rightmost parts
>> > of HELO match the MAILFROM domain using spfv1.
>>
>> The ptr mechanism, which should be abandoned IMHO, does this. But indeed
>> that needs a properly setup DNS. It seems that you propose something like
>> "heloptr" which would use the HELO parameter instead of what is found in
>> the
>> in-addr.arpa part of the DNS tree. Those who are unable or unwilling to
>> setup DNS correctly, won't understand that "heloptr" would also match
>> dyn-10-1-2-3.customer.example.com. This may or may not be harmful, but is
>> probably not what was intended.
>
> It is what was intended. When example.com contracts with bigisp.com to
> provide a dsl account with a small static IP block (typically /29), the
> problem
> is that bigisp.com is typically unable to reliably provide PTR records
> chosen by example.com[*]. However, the PTR record they do chose will
> be something like 'dyn-10-1-2-3.bigisp.com', *not*
> 'dyn-10-1-2-3.example.com',
> (never mind that the contract is for static ips).

I chose "example.com" because of RFC 2606. Anyway...

Why would dyn-10-1-2-4.bigisp.com need to be authorized?
(notice: 4, not 3)
After all, if you're going to take the rightmost part of the HELO string,
both end in bigisp.com or in example.com, whatever it is you're trying to
tell us ...


I may not be the smartest one on this list but I'm not stupid and I don't
understand what you're trying to do. Perhaps you should write an example
smtp dialog, including some remarks where and why your "heloptr" would make
a difference, to make clear what you want. Thanks.



-------------------------------------------
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

On Mon, 13 Jul 2009, Alex van den Bogaerdt wrote:

> > HELO is "validated" in the same way a PTR record is - by checking for
> > a match with connect ip.
>
> My point is: either DNS is setup correctly, PTR records are setup, or it
> isn't. "... find it difficult to get their ISP to maintain PTR records." seems
> to indicate that DNS is not setup correctly.

Unfortunately, clients have no direct control over PTR records when their
IP block is less than 256 IPs (most small businesses). All other DNS RRs
can be directly controlled by a competent admin, no matter how small -
but not PTR. When the ISP is unresponsive, the only recourse is to
change providers - and broadband is very often a monopoly.

> AFAIK the ptr mechanism does not tie helo to the mail domain.

Correct, hence the proposal.

> Verifying that the connected IP and the HELO parameter match, is done using
> the "a" mechanism.

If there is only one, or a small number of HELOs. Which is probably
reasonable given that the use case assumes < 256 IPs.

> 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".

I am talking about using the name provided by HELO to validate a MAIL FROM
identity - not the HELO identity. Providing names via PTR is often difficult
or impossible for a small company due to lack of direct control - but HELO is
always available and directly configured by a mail admin.

> Why would dyn-10-1-2-4.bigisp.com need to be authorized?

It doesn't. The issue is that example.com can't convice bigisp.com
(which is a broadband monopoly in the area) to install proper PTR
records for the static IPs example.com is paying for (despite a
contract saying they are supposed to). More precisely, my experience
has been that it takes an average 3 days and 3 hours on the phone to convince
a DNS flunky to make one change. And then, they often mistype
the entry and you have to do it again. It is just not worth the time and
effort unless some automated system is in place like PTR delegation
(which can be cached at bigisp and made to look like non-delegated records
to avoid any performance issues) or a web admin app.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.


-------------------------------------------
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

At 18:01 13/07/2009 Monday, Stuart D. Gathman wrote:
>On Fri, 10 Jul 2009, alan wrote:
>
>> At 21:52 10/07/2009 Friday, Stuart D. Gathman wrote:
>> >In my "best-guess" algorithm, a validated HELO (that resolves to the connect ip)
>> >is added to the collection of validated PTR records for the PTR mechanism.
>> >
>>
>> untrue:
>> example if a spammer has a bot infecting my home pc
>> ptr host244.freudenhaus.alandoherty.net
>> he can quite happily connect to you and helo as mail.spammersdomain.com
>> and have ensured that mail.spammersdomain.com points at my ip {and possibly 100 others, ok 5 }
>> thus passing your test but proving nothing of his authenticity {as we know the ip is mine not his}
>
>You wouldn't put ptr:spammersdomain.com in your SPF policy (would you?).

yes but i wouldn't be wanting to send email via non-legit MTA's

spammer at spammerdomain do want mail via non-legit mta's to pass receiver policies
{50cents each through most Chinese registrars}
they just register more domains as the old one get blacklisted at a cost of 50 cent a week ish}


>It proves that the email was controlled by spammersdomain.com, and
>that is the domain that gets blacklisted, not alandoherty.net.

but as i say this is always too little too late


>> the checking of ptr > name > ip
>> is a method of validating the ip's identity not the helo or the spf records

in other words senders/receivers use SPF to control forgeries

ptr > name > ip
{is a check done entirely independently of SPF DKIM etc not to control forgeries
just to control un-forged {and no SPF or permissive SPF, forged} spam

>HELO > name > ip validates helo.
>
>> you can already authorize ips you have no ptr setup for in your spf
>
>That is a fair point: probably strong enough to withdraw the proposal.
>Since you (the sender) control the HELO, you can always provide a A mechanism
>instead for an SPF policy.

exactly
{or like we require if you want a broken ptr whitelisted here
to be accepted you MUST helo as hostname.yourdomain.tld not yourdomain.tld {all too common mistake}
you must setup an A for hostname.yourdomain.tld pointing to the connecting ip(s)
you must setup an SPF for hostname.yourdomain.tld terminating -all only authorising the same ip(s)
we encourage setting up a CSV for hostname.yourdomain.tld only authorising the same ip(s)


>The enhanced PTR (or HELO) mechanism is only really useful in
>best-guess algorithms. I was just hoping to help standardize guessing a
>little.

the whole concept of best guess algorithms I find ham fisted



-------------------------------------------
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

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@smtp-out.example.com, not
user@example.com unless example.com has an A record with the same
number. (In that case it could have just said "HELO example.com".)

> I am talking about using the name provided by HELO to validate a MAIL FROM
> identity - not the HELO identity.

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@example.com and one
from user@example.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

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@smtp-out.example.com, not user@example.com unless example.com has an A record with the same number.

the helo is validated by testing the for an spf for postmaster@smtp-out.example.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@example.com and one from user@example.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

On Tue, 14 Jul 2009, Alessandro Vesely wrote:

> Would "a:%{h2}" do the trick here?

No. However, a hypothetical extension to compare literals would:
"cmp:%{h2}==%{d}" if the policy also validates the HELO name (possible
but convoluted in SPFv1).

I posted an example of intended use of HELO mechanism separately.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.


-------------------------------------------
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

At 16:05 14/07/2009 Tuesday, Stuart D. Gathman wrote:
>On Tue, 14 Jul 2009, Alessandro Vesely wrote:
>
>> Would "a:%{h2}" do the trick here?
>
>No. However, a hypothetical extension to compare literals would:
>"cmp:%{h2}==%{d}" if the policy also validates the HELO name (possible
>but convoluted in SPFv1).
>
>I posted an example of intended use of HELO mechanism separately.

actually it could ish

v=spf1 a:{h4r}.smtp.example.com -all

would directly equate to your example

ie pass where yours passes fail where yours fails



-------------------------------------------
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

On Tue, 14 Jul 2009, alan wrote:

> >I posted an example of intended use of HELO mechanism separately.
>
> actually it could ish
>
> v=spf1 a:{h4r}.smtp.example.com -all
>
> would directly equate to your example
>
> ie pass where yours passes fail where yours fails

No, it doesn't validate the HELO name.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.


-------------------------------------------
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

At 01:49 15/07/2009 Wednesday, Stuart D. Gathman wrote:
>On Tue, 14 Jul 2009, alan wrote:
>
>> >I posted an example of intended use of HELO mechanism separately.
>>
>> actually it could ish
>>
>> v=spf1 a:{h4r}.smtp.example.com -all
>>
>> would directly equate to your example
>>
>> ie pass where yours passes fail where yours fails
>
>No, it doesn't validate the HELO name.

yes it does {for your example}

it only passes if the connecting ip
matches the ip of the lookup of the A of
the first segment of the helo name appended to smtp.example.com

ie xx.smtp.example.com so if they claim to be xx.yyy.zzz.aa from any ip other than the ip of xx.smtp.example.com they fail

thus helo only validates for xx.smtp.example.com and correct ip

{there is no need to validate helo if the end result will be a fail for other reasons {wrong helo name/domain}}



-------------------------------------------
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