Mailing List Archive

At 17:52 19/01/2009 Monday, you wrote:
>Hi all,
>I'd like to be comforted by usage statistics, but have no data. My
>understanding of SPF checks by scope is as follows:
>
>
>helo: could work always, however hostmasters don't usually add all
>necessary DNS records; easily worked around using address literals.

not really as address literals may be RFC compliant, but no actual MTA would really expect to survive using them,
thus most sites/servers doing spamfiltering of any sort only accept them from internal-ranges
and smtp-submission-port clients
my own server responds with "your helo/ehlo was an address literal you can only contact postmaster till your systems setup is complete"
on any of those {too few to mention {handfull a month} that arn't also on RBLS}


>mfrom: provides some protection (proportional to adoption); requires
>SRS or other machinery in case of forwarding; difficult to test and debug.

srs or per recipient {recipient-controlable} whitelists {which any decent MTA in this day and age should do, many do even some of the big webmails}
not horribly difficult to test /debug many servers offer an echo@ address where it will echo back a copy of the original with their spf headers added

>pra: only works for bots, banks, or domains whose users never write to
>a mailing list (unless the list adds resent-* headers; any?)

most mailinglists have worked with it {before pra even happened} for years {but obviously the mailinglists it breaks are distribution lists such as sales@company when its essentially a forward to many {thus no content opened/modified on way through}

so easier to say pra broken by forwarding even if SRS is used
{requires newer SRS-+inject headers}

>Visibility is easily worked around using resent-* headers.

if those headers present its the pra of the re-sender that is checked not the original sender
so same requirement to list his/her mailhosts in the pra details for the resent headers is still important
and adding arbitary resent-* headers won't work if the identities in them don't have sender-id




>Is that correct/agreed?
>Article:
>http://www.listbox.com/member/archive/735/2009/20090120053903:91507D60-E6DE-11DD-A795-A2E3A49B9427/



-------------------------------------------
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, 20 Jan 2009 11:38:34 +0100 Alessandro Vesely <vesely@tana.it> wrote:
>Hi all,
>I'd like to be comforted by usage statistics, but have no data. My
>understanding of SPF checks by scope is as follows:
>
>
>helo: could work always, however hostmasters don't usually add all
>necessary DNS records; easily worked around using address literals.

It does seem to me to be increasing based on my occassional looks at
results from the SPF test reflector I run from the project. More
evangelism and better documentation is needed (who was going to send me web
site changes ??).

>mfrom: provides some protection (proportional to adoption); requires
>SRS or other machinery in case of forwarding; difficult to test and debug.

The biggest problem with mfrom is it requires domain owners to understand
and control their outbound email architecture. It's only hard to debug if
you don't understand your systems. This is quite common and one of the
reasons for long deployment times in large organizations.

Forwarding is an issue, but I think manageable. It's a tiny and declining
fraction of email.

In the long run traditional forwarding is, IMO, dead. Any forwarder will
inevitably forward enough spam to get blacklisted or lose enough mail to be
unreliable.

Generally, the only forwarding relationships that will survive are ones
where the receiver has made specific arrangements to bypass normal spam
checks. SPF checks would fall into this.

If a sender is genuinely concerned about the forwarding problem they can
use one of SRS/SES/BATV and an SPF record with exists backed by a DNS
database to explicitly authorize forwarded mail.

SRS would work too.

>pra: only works for bots, banks, or domains whose users never write to
>a mailing list (unless the list adds resent-* headers; any?)
>Visibility is easily worked around using resent-* headers.

PRA is useful only to a receiver as an input key to domain reputation
database. DKIM is a better way to solve this exact problems. For senders,
PRA is a very handy way to protect the resent-sender header.

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