Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: SPF: Discuss

SPFv3 idea: recipient domain macro for exists

  

 
SPF discuss RSS feed   Index | Next | Previous | View Threaded


michael at talamasca

Jul 17, 2009, 4:26 AM

Post #1 of 17 (3164 views)
Permalink
SPFv3 idea: recipient domain macro for exists
I had one idea on how a sender could cope with an unhandled forwarder
problem or unwhitelisted backup MX in some receivers, without completely
giving up the benefits of SPF fail: Maintain an RHSBL of *recipient* domains
which do not handle SPF properly, and then use a ?exists mechanism to query
it and return neutral for matches, ahead of the -all or ~all sane recipients
will see.

Sadly, when I looked up the RFC to see exactly how to write such an exists
line, I found it's impossible in SPFv1. There are macros for the sender
local-part and domain, but nothing for the recipient.

So, I propose rectifying that in SPFv3. We just need to add a new macro
that expands to the RCPT TO domain of an attempted SMTP transaction. Might
as well add one for local-part, too.


The feature also has a second use. The VERP/exists/magic-DNS senderside
mitigation method could benefit if the recipient domain could be presented to
the magic DNS server. A forger, even if he could guess or snoop the tumbler
on the MAIL FROM, would be only be able to send bogus e-mails to people the
victim very recently corresponded with.

---- Michael Deutschmann <michael [at] talamasca>


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

Jul 17, 2009, 11:09 AM

Post #2 of 17 (3093 views)
Permalink
Re: SPFv3 idea: recipient domain macro for exists [In reply to]
On Fri, 17 Jul 2009, Michael Deutschmann wrote:

> I had one idea on how a sender could cope with an unhandled forwarder
> problem or unwhitelisted backup MX in some receivers, without completely
> giving up the benefits of SPF fail: Maintain an RHSBL of *recipient* domains
> which do not handle SPF properly, and then use a ?exists mechanism to query
> it and return neutral for matches, ahead of the -all or ~all sane recipients
> will see.

A *great* idea.

> Sadly, when I looked up the RFC to see exactly how to write such an exists
> line, I found it's impossible in SPFv1. There are macros for the sender
> local-part and domain, but nothing for the recipient.
>
> So, I propose rectifying that in SPFv3. We just need to add a new macro
> that expands to the RCPT TO domain of an attempted SMTP transaction. Might
> as well add one for local-part, too.

Since everyone is shooting down my v3 ideas with "here's how you could
do it in v1", let me shoot yours down. :-) All(!) you have to do is
have your MTAs encode the sender in the helo name it uses when
transmitting the email. For instance, assign an ID number to every
recipient in your "braindead" list. Use BDnnnnnnnn.smtp.example.com
as the HELO name in your MTA, where nnnnnnnn is the ID assigned to the
braindead recipient.

--
Stuart D. Gathman <stuart [at] bmsi>
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


spfdiscuss at alandoherty

Jul 17, 2009, 11:53 AM

Post #3 of 17 (3096 views)
Permalink
Re: SPFv3 idea: recipient domain macro for exists [In reply to]
At 19:09 17/07/2009 Friday, Stuart D. Gathman wrote:
>On Fri, 17 Jul 2009, Michael Deutschmann wrote:
>
>> I had one idea on how a sender could cope with an unhandled forwarder
>> problem or unwhitelisted backup MX in some receivers, without completely
>> giving up the benefits of SPF fail: Maintain an RHSBL of *recipient* domains
>> which do not handle SPF properly, and then use a ?exists mechanism to query
>> it and return neutral for matches, ahead of the -all or ~all sane recipients
>> will see.
>
>A *great* idea.

a very useful idea
it gets my vote just for utility even if used for entirely different purpose a recipient address macro would be useful programatically as it does offer something unachievable in spf1


>> Sadly, when I looked up the RFC to see exactly how to write such an exists
>> line, I found it's impossible in SPFv1. There are macros for the sender
>> local-part and domain, but nothing for the recipient.
>>
>> So, I propose rectifying that in SPFv3. We just need to add a new macro
>> that expands to the RCPT TO domain of an attempted SMTP transaction. Might
>> as well add one for local-part, too.
>
>Since everyone is shooting down my v3 ideas with "here's how you could
>do it in v1", let me shoot yours down. :-) All(!) you have to do is
>have your MTAs encode the sender in the helo name it uses when
>transmitting the email. For instance, assign an ID number to every
>recipient in your "braindead" list. Use BDnnnnnnnn.smtp.example.com
>as the HELO name in your MTA, where nnnnnnnn is the ID assigned to the
>braindead recipient.

A I'm hoping its a joke
B the helo is invariant it should not change from one connection to the next and if it does the machine often triggers anti-bot detection systems
C most MTA's have no method to change the helo without restart
D then you have the headache of maintaining the A records for all thes helo's and the spf records for all these helo's {+CSV or any other record types that get used to validate HELO in the future}




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

Jul 17, 2009, 1:27 PM

Post #4 of 17 (3092 views)
Permalink
Re: SPFv3 idea: recipient domain macro for exists [In reply to]
On Fri, 17 Jul 2009, alan wrote:

> >Since everyone is shooting down my v3 ideas with "here's how you could
> >do it in v1", let me shoot yours down. :-) All(!) you have to do is
> >have your MTAs encode the sender in the helo name it uses when
> >transmitting the email. For instance, assign an ID number to every
> >recipient in your "braindead" list. Use BDnnnnnnnn.smtp.example.com
> >as the HELO name in your MTA, where nnnnnnnn is the ID assigned to the
> >braindead recipient.
>
> A I'm hoping its a joke

Yes, it's a joke.
"Doable" often means "too painfully ugly to actually implement".

> B the helo is invariant it should not change from one connection to the next and if it does the machine often triggers anti-bot detection systems

The HELO would always be the same for a given recipient domain, so it won't
trigger the anti-bot systems.

> C most MTA's have no method to change the helo without restart

So don't use one of those inflexible MTAs. :-)

In the case of sendmail, just use a Socketmap for the %j macro (or
copy a Socketmap macro to %j on each connection for efficiency).

> D then you have the headache of maintaining the A records for all thes helo's
> and the spf records for all these helo's {+CSV or any other record types that
> get used to validate HELO in the future}

Just use a wild card in DNS.

*.smtp.example.com IN A 1.2.3.4

--
Stuart D. Gathman <stuart [at] bmsi>
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


stuart at bmsi

Jul 17, 2009, 7:38 PM

Post #5 of 17 (3093 views)
Permalink
Re: SPFv3 idea: recipient domain macro for exists [In reply to]
On Fri, 17 Jul 2009, Stuart D. Gathman wrote:

> > B the helo is invariant it should not change from one connection to the
> > next and if it does the machine often triggers anti-bot detection systems
>
> The HELO would always be the same for a given recipient domain, so it won't
> trigger the anti-bot systems.
>
> > C most MTA's have no method to change the helo without restart
>
> So don't use one of those inflexible MTAs. :-)
>
> In the case of sendmail, just use a Socketmap for the %j macro (or
> copy a Socketmap macro to %j on each connection for efficiency).

Even better, use just 2 MTAs - each with a fixed HELO. Route
email for normal recipients to normal.smtp.example.com, and email
for braindead recipients to lifesupport.smtp.example.com. Make sure
the policy rejects on invalid helo before passing on a HELO of
lifesupport.smtp.example.com.

This variation would actually be practical for SPFv1. I already have to do
something like this for SRS/VERP/BATV style signing of MAIL FROM. Some
recipients ignore rfc2821 and have their own undocumented allowed character
set for localpart and are marked 'nosrs'.

> > D then you have the headache of maintaining the A records for all thes
> > helo's and the spf records for all these helo's {+CSV or any other record
> > types that get used to validate HELO in the future}

Now there are just 2 A records.

--
Stuart D. Gathman <stuart [at] bmsi>
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


vesely at tana

Jul 18, 2009, 3:39 AM

Post #6 of 17 (3089 views)
Permalink
Re: SPFv3 idea: recipient domain macro for exists [In reply to]
Stuart D. Gathman wrote:
> Even better, use just 2 MTAs - each with a fixed HELO. Route
> email for normal recipients to normal.smtp.example.com, and email
> for braindead recipients to lifesupport.smtp.example.com. Make sure
> the policy rejects on invalid helo before passing on a HELO of
> lifesupport.smtp.example.com.

Is that supposed to be simpler than changing the MAIL FROM parameter?



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


michael at talamasca

Jul 18, 2009, 7:36 AM

Post #7 of 17 (3092 views)
Permalink
Re: SPFv3 idea: recipient domain macro for exists [In reply to]
On Fri, 17 Jul 2009, Stuart D. Gathman wrote:
> Since everyone is shooting down my v3 ideas with "here's how you could
> do it in v1", let me shoot yours down. :-) All(!) you have to do is
> have your MTAs encode the sender in the helo name it uses when
> transmitting the email.

That won't work. The problem cases involve hops after the e-mail leaves the
sender's servers. The HELO the broken receiver will see, will be the name of
the backup MX, or the forwarder's mailserver -- not what the sender used.

---- Michael Deutschmann <michael [at] talamasca>


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

Jul 18, 2009, 8:45 AM

Post #8 of 17 (3089 views)
Permalink
Re: SPFv3 idea: recipient domain macro for exists [In reply to]
On Sat, 18 Jul 2009, Michael Deutschmann wrote:

> On Fri, 17 Jul 2009, Stuart D. Gathman wrote:
> > Since everyone is shooting down my v3 ideas with "here's how you could
> > do it in v1", let me shoot yours down. :-) All(!) you have to do is
> > have your MTAs encode the sender in the helo name it uses when
> > transmitting the email.
>
> That won't work. The problem cases involve hops after the e-mail leaves the
> sender's servers. The HELO the broken receiver will see, will be the name of
> the backup MX, or the forwarder's mailserver -- not what the sender used.

Duh. I'm an idiot.

--
Stuart D. Gathman <stuart [at] bmsi>
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


spfdiscuss at alandoherty

Jul 18, 2009, 9:42 AM

Post #9 of 17 (3092 views)
Permalink
Re: SPFv1 cleanup [In reply to]
I think 1 important spfv1 cleanup idea is to warn strongly about sender-id's

mis-appropriation of spfv1 records and syntax
and thus a good spfv1 implementating domain should avoid this via say a minimum of


example.com v=spf1 redirect=_spf1.%{o}
spf2.0/mfrom redirect=_spfm2.%{o}
spf2.0/pra redirect=_spfp2.%{o}

and having the actual spf1 record under

_spf1 v=spf1 {details}
_spfm2 spf2.0/mfrom (same details)

and i a pra {sender-id} believer use it or if just a SPF believer have

_spfp2 spf2.0/pra ?all


{i personally do a combo like this but use a redirect=%{l}._spf1.%{o} for all so each user can personalize their use/non-use -all/~all/?all themselves}
all non-existent envelopes get a v=spf1 -all or spf2.0/mfrom,pra -all
and some special cases like mailer-deamon@ have a spf2.0/pra ?all but a v=spf1 -all or spf2.0/mfrom -all
as they never are used in envelope



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


spfdiscuss at alandoherty

Jul 18, 2009, 10:15 AM

Post #10 of 17 (3099 views)
Permalink
Re: SPFv1 cleanup resend with typos corrected [In reply to]
At 17:42 18/07/2009 Saturday, alan wrote:
>I think 1 important spfv1 cleanup idea is to warn strongly about sender-id's
>
>mis-appropriation of spfv1 records and syntax
>and thus a good spfv1 implementating domain should avoid this via say a minimum of
>
>
>example.com v=spf1 redirect=_spf1.%{o}
> spf2.0/mfrom redirect=_spfm2.%{o}
> spf2.0/pra redirect=_spfp2.%{o}
>
>and having the actual spf1 record under
>
>_spf1 v=spf1 {details}
>_spfm2 spf2.0/mfrom (same details)
>
>and if a pra {sender-id} believer use it, or if just a SPF believer have
>
>_spfp2 spf2.0/pra ?all
>
>
>{i personally do a combo like this but use a redirect=%{l}._spf1.%{o} for all so each user can personalize their use/non-use -all/~all/?all themselves}
>all non-existent envelopes get a v=spf1 -all or spf2.0/mfrom,pra -all
>and some special cases like mailer-deamon@ have a spf2.0/pra ?all but a v=spf1 -all or spf2.0/mfrom -all
>as they never are used in envelope
>
>
>
>-------------------------------------------
>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


hannah at schlund

Jul 20, 2009, 5:19 AM

Post #11 of 17 (3099 views)
Permalink
Re: SPFv3 idea: recipient domain macro for exists [In reply to]
Hi!

On Fri, Jul 17, 2009 at 04:26:58AM -0700, Michael Deutschmann wrote:
>[...]

>So, I propose rectifying that in SPFv3. We just need to add a new macro
>that expands to the RCPT TO domain of an attempted SMTP transaction. Might
>as well add one for local-part, too.

*Which* RCPT to domain should it expand in this transaction:

HELO a.first.example.com
MAIL FROM: <user [at] first>
RCPT TO: <user1 [at] second>
RCPT TO: <user2 [at] third>

(Where the MX records for second and third point to the same machine so
the sending MTA delivers the mail to both recipients in the same
transaction...)

Kind regards,

Hannah.


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


spfdiscuss at alandoherty

Jul 20, 2009, 8:43 AM

Post #12 of 17 (3084 views)
Permalink
Re: SPFv3 idea: recipient domain macro for exists [In reply to]
At 13:19 20/07/2009 Monday, Hannah Schroeter wrote:
>Hi!
>
>On Fri, Jul 17, 2009 at 04:26:58AM -0700, Michael Deutschmann wrote:
>>[...]
>
>>So, I propose rectifying that in SPFv3. We just need to add a new macro
>>that expands to the RCPT TO domain of an attempted SMTP transaction. Might
>>as well add one for local-part, too.
>
>*Which* RCPT to domain should it expand in this transaction:
>
> HELO a.first.example.com
> MAIL FROM: <user [at] first>
> RCPT TO: <user1 [at] second>
> RCPT TO: <user2 [at] third>
>
>(Where the MX records for second and third point to the same machine so
>the sending MTA delivers the mail to both recipients in the same
>transaction...)
>
>Kind regards,
>
>Hannah.

i would assume the assumption is the spf would be being verified as standard after each rcpt To: command is issued
{why spf looks currently only at helo and "mail from"}
{to return an accept or reject for that recipient depending on their SPF/reject/ignore/tag policy+result}

but if spf is being checked elswhere {say after data} it would have to have either to be decided by receivers implementation choice

hopefully no "wild" implementations leave it so late

but it does make forwarder mitigation via this macro potentially problematic

as a workaround it could be ONLY syntactically legal within an optional extra include/exists
and that clients not fed {recomended extra} rcpt-to info would ignore such optional extra includes/exists

and if such clients are end destination of forwarders hope they properly whitelist their forwarders {as this feature won't be available for senders to correct the error}



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

Jul 20, 2009, 5:33 PM

Post #13 of 17 (3086 views)
Permalink
Re: SPFv3 idea: recipient domain macro for exists [In reply to]
On Mon, 20 Jul 2009, Hannah Schroeter wrote:

> >So, I propose rectifying that in SPFv3. We just need to add a new macro
> >that expands to the RCPT TO domain of an attempted SMTP transaction. Might
> >as well add one for local-part, too.
>
> *Which* RCPT to domain should it expand in this transaction:
>
> HELO a.first.example.com
> MAIL FROM: <user [at] first>
> RCPT TO: <user1 [at] second>
> RCPT TO: <user2 [at] third>

All of them. The result would be per recipient.

--
Stuart D. Gathman <stuart [at] bmsi>
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


vesely at tana

Jul 21, 2009, 4:06 AM

Post #14 of 17 (3095 views)
Permalink
Re: SPFv3 idea: recipient domain macro for exists [In reply to]
alan wrote:
> At 13:19 20/07/2009 Monday, Hannah Schroeter wrote:
>>*Which* RCPT to domain should it expand in this transaction:
>>
>> HELO a.first.example.com
>> MAIL FROM: <user [at] first>
>> RCPT TO: <user1 [at] second>
>> RCPT TO: <user2 [at] third>
>
> i would assume the assumption is the spf would be being verified as standard after each rcpt To: command is issued

That would be redundant in this case, since both second.example.com
and third.example.com have a common MX, which is the machine receiving
the commands above. I note that, unless one makes braindead
comparisons between HELO and MAIL FROM, the receiving server doesn't
know whether the message is being forwarded, rather than delivered
directly.

> {why spf looks currently only at helo and "mail from"}

HELO is unreliable because it may be an IP address, it may be
anything, and even if it is correct one cannot reliably infer the mail
domain name by stripping its leftmost label, as stated in rfc 5507.

MAIL FROM is the first command where the receiving server learns the
mail domain of the transmitting server. Even if it's not its original
purpose. Even if it may be empty.

If there were a command whose argument consisted of the domain name,
e.g. "VHLO example.com", SPF would be perfect for authenticating a
transmitter as SMTP-authorized member of a mail domain. IMHO, that's
SPF's strong suite.

> {to return an accept or reject for that recipient depending on their SPF/reject/ignore/tag policy+result}

In plain English, the SPF record would say "I know you're broken, so
please forget about any SPF results that are intended for smart
recipients only."

> but if spf is being checked elswhere {say after data} it would have to have either to be decided by receivers implementation choice

That makes sense, since the recipient presumably knows better whether
it is broken.

> hopefully no "wild" implementations leave it so late

SpamAssassin is an example. It interprets Received headers, determines
the addresses and reckons how SPF authorizations contribute to a
message spamminess. SA may be configured to whitelist_by_spf on a per
mail domain basis. I'd guess this use of SPF outscores rejecting
forgeries before DATA.



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


scott at kitterman

Jul 21, 2009, 4:53 AM

Post #15 of 17 (3087 views)
Permalink
Re: SPFv3 idea: recipient domain macro for exists [In reply to]
On Tue, 21 Jul 2009 13:06:54 +0200 Alessandro Vesely <vesely [at] tana> wrote:
...
>> hopefully no "wild" implementations leave it so late
>
>SpamAssassin is an example. It interprets Received headers, determines
>the addresses and reckons how SPF authorizations contribute to a
>message spamminess. SA may be configured to whitelist_by_spf on a per
>mail domain basis. I'd guess this use of SPF outscores rejecting
>forgeries before DATA.

Agreed. To the extent I'm aware of it, all large providers that check SPF
do it post-SMTP. The timeline for DNS lookups is believed to be
problematic at high volumes. I have a theory that needed data will be in
the local cache almost always, so it won't have a major effect, but I've
never been in a position to test this with data.

Scott K


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

Jul 21, 2009, 6:46 AM

Post #16 of 17 (3083 views)
Permalink
Re: SPFv3 idea: recipient domain macro for exists [In reply to]
On Tue, 21 Jul 2009, Scott Kitterman wrote:

> On Tue, 21 Jul 2009 13:06:54 +0200 Alessandro Vesely <vesely [at] tana> wrote:
> ...
> >SpamAssassin is an example. It interprets Received headers, determines
> >the addresses and reckons how SPF authorizations contribute to a
> >message spamminess. SA may be configured to whitelist_by_spf on a per
> >mail domain basis. I'd guess this use of SPF outscores rejecting
> >forgeries before DATA.
>
> Agreed. To the extent I'm aware of it, all large providers that check SPF
> do it post-SMTP. The timeline for DNS lookups is believed to be
> problematic at high volumes. I have a theory that needed data will be in
> the local cache almost always, so it won't have a major effect, but I've
> never been in a position to test this with data.

I would hope SA can be configured to use the Received-SPF header instead.
Shouldn't a large provider throw in a milter/plugin/SMTPsink/whatever
to add Received-SPF at SMTP time, even if no rejecting is done?

--
Stuart D. Gathman <stuart [at] bmsi>
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


scott at kitterman

Jul 21, 2009, 11:45 AM

Post #17 of 17 (3087 views)
Permalink
Re: SPFv3 idea: recipient domain macro for exists [In reply to]
On Tue, 21 Jul 2009 09:46:58 -0400 (EDT) "Stuart D. Gathman"
<stuart [at] bmsi> wrote:
>On Tue, 21 Jul 2009, Scott Kitterman wrote:
>
>> On Tue, 21 Jul 2009 13:06:54 +0200 Alessandro Vesely <vesely [at] tana>
wrote:
>> ...
>> >SpamAssassin is an example. It interprets Received headers, determines
>> >the addresses and reckons how SPF authorizations contribute to a
>> >message spamminess. SA may be configured to whitelist_by_spf on a per
>> >mail domain basis. I'd guess this use of SPF outscores rejecting
>> >forgeries before DATA.
>>
>> Agreed. To the extent I'm aware of it, all large providers that check
SPF
>> do it post-SMTP. The timeline for DNS lookups is believed to be
>> problematic at high volumes. I have a theory that needed data will be
in
>> the local cache almost always, so it won't have a major effect, but I've
>> never been in a position to test this with data.
>
>I would hope SA can be configured to use the Received-SPF header instead.
>Shouldn't a large provider throw in a milter/plugin/SMTPsink/whatever
>to add Received-SPF at SMTP time, even if no rejecting is done?

It does consume Received-SPF instead of doing its own lookup if it's
available.

Scott K


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

SPF discuss RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.