Mailing List Archive

On Thu, 9 Jul 2009, Alessandro Vesely wrote:

> A hack is a hack. For one, there is no administrative relationship between
> mailout.biguni.edu and biguni.edu itself (rfc5507).

It doesn't matter. All that matters is the MAIL FROM domain on outgoing
mail from the forwarder.

--
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 20:17 09/07/2009 Thursday, Stuart D. Gathman wrote:
>On Thu, 9 Jul 2009, Alessandro Vesely wrote:
>
>> A hack is a hack. For one, there is no administrative relationship between
>> mailout.biguni.edu and biguni.edu itself (rfc5507).
>
>It doesn't matter. All that matters is the MAIL FROM domain on outgoing
>mail from the forwarder.

the mail from domain after forwarding is unchanged!!!!!!!!!!!!

otherwise you are not forwarding you are SRS-forwarding

SRS-forwarding already works with SPF thus is outside this discussion

were discussing only non-SRS or traditional forwarding

the kind done by every MTA by default

{forwarding where the software hasn't been re-written to suit the wims of those receivers
doing SPF checking without white listing their users forwarders}



-------------------------------------------
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 Thu, 9 Jul 2009, alan wrote:

> >> A hack is a hack. For one, there is no administrative relationship between
> >> mailout.biguni.edu and biguni.edu itself (rfc5507).
> >
> >It doesn't matter. All that matters is the MAIL FROM domain on outgoing
> >mail from the forwarder.
>
> the mail from domain after forwarding is unchanged!!!!!!!!!!!!
>
> otherwise you are not forwarding you are SRS-forwarding

You aren't getting it. *Pretend* they are SRS-forwarding (even though
they really aren't). Now, what domain are they using in MAIL FROM in the
pretend SRS-forward (in your minds eye)? Usually, it is the same as the domain
you would use to email the forwarder about billing, subscription,
complaints, etc.

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

Michael Deutschmann wrote:
> The problem is that, like Microsoft SenderID, V-SPF is compromising the
> effectiveness of G-SPF by leading senders to be timid in their SPF records.

I don't see much differences among various flavors (G, V, D) of SPF.
Senders who mean SPF to only be used for whitelisting desire that
receivers set, say, whitelist_from_spf in sa, and already have ~all or
?all to choose from. Senders who mean SPF to also reject forgeries set
-all.

I've always thought that we like -all better because it rejects
forgeries. You say that it would be better not to reject forgeries
because then more domains can set -all. But what would that be good
for? Whitelisting won't be whiter on "pass" when the default is -all.

The ability to reject forgeries before getting the DATA has always
characterized SPF as a different tool than SenderID. There is no point
in accepting forgeries. However, in some circumstances forgeries
cannot be easily detected. For example, sending paths for a given
domain may vary because not all users submit on domain's port 587.
Happy softfail or neutral, then.

Besides using SUBMIT, there is the example of those sloppy forwarders
at biguni.edu, which is contrary to a number of practices, including
the fact that the recipient may or may not be able to change/delete
that .forward file depending on unforeseeable circumstances.
Forwarding with an empty MAIL FROM is just as easy and doesn't break
anything, for that case. If the postmasters at biguni really care,
they can forward setting bounces to themselves, so that as soon as
they get one they can delete that dismissed account (and its .forward
file) for good.



-------------------------------------------
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, Alessandro Vesely wrote:
> Michael Deutschmann wrote:
> > The problem is that, like Microsoft SenderID, V-SPF is compromising the
> > effectiveness of G-SPF by leading senders to be timid in their SPF records.
>
> I don't see much differences among various flavors (G, V, D) of SPF.
> Senders who mean SPF to only be used for whitelisting desire that
> receivers set, say, whitelist_from_spf in sa, and already have ~all or
> ?all to choose from. Senders who mean SPF to also reject forgeries set
> -all.
But this approach hurts the mailboxes where a forwarder whitelist is
available. If the sender had given the whole story in its SPF record, the
receiver could reject forgeries with no false positive risk.


Look at it this way -- there are five kinds of practical forwarding
problem mitigation:

Crap Receiverside -- Treat all SPF results as if they were the most
permissive of the actual result and Neutral.

Elite Receiverside -- Use a forwarder whitelist to give a virtual Pass to
forwarded mail, otherwise apply actual SPF result.

Forwarderside -- Use SRS, or at least sham-SRS (changing the MAIL FROM, but
making no arrangement to relay bounces).

Crap Senderside -- Write the SPF policy to give the most permissive of the
correct result (from a G-SPF perspective) and neutral.

Elite Senderside -- Use VERP, the exists mechanism, and a magical DNS
server.

Any one of these will eliminate false positives due to the forwarding
problem. But both Crap Receiverside and Crap Senderside cause a horrendous
increase in false negatives.

If neither Elite method existed, then the loss from G-SPF or V-SPF confusion
would be minimal in practice -- since no one would use softdeny or fail, and
no one would believe them anyway.

But the G-SPF/V-SPF confusion costs SPF a chance to shine when Elite
mitigation is available.

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

Michael Deutschmann wrote:
> On Fri, 10 Jul 2009, Alessandro Vesely wrote:
>> Michael Deutschmann wrote:
>> > The problem is that, like Microsoft SenderID, V-SPF is compromising the
>> > effectiveness of G-SPF by leading senders to be timid in their SPF records.
>>
>> I don't see much differences among various flavors (G, V, D) of SPF.
>> Senders who mean SPF to only be used for whitelisting desire that
>> receivers set, say, whitelist_from_spf in sa, and already have ~all or
>> ?all to choose from. Senders who mean SPF to also reject forgeries set
>> -all.
> But this approach hurts the mailboxes where a forwarder whitelist is
> available. If the sender had given the whole story in its SPF record, the
> receiver could reject forgeries with no false positive risk.

I got it: you mean a site where all users use SUBMIT properly, but are
worried about unwittingly forwarded messages that they cannot control.
They would want to tell receivers to drop forgeries unless they come
from forwarders.

The problem is that you have no way, except by carefully checking
Received and DKIM-Signature headers, to know whether a message has
been forwarded. If such a method existed, a "forwarder" mechanism
would be welcome. One could say +forwarder, ~forwarder, or whatever,
which would match when the connecting client is a forwarder.

What about forwarders who happened to miss that whitelist?

> Look at it this way -- there are five kinds of practical forwarding
> problem mitigation:
>
> Crap Receiverside -- Treat all SPF results as if they were the most
> permissive of the actual result and Neutral.

?forwarder ?all

> Elite Receiverside -- Use a forwarder whitelist to give a virtual Pass to
> forwarded mail, otherwise apply actual SPF result.

+forwarder -all (this breaks SPF as an authentication mechanism)

> But the G-SPF/V-SPF confusion costs SPF a chance to shine when Elite
> mitigation is available.

Yes, mail domains cannot have sharp SPF records because they cannot
control whether their _recipients_ use forwarding. Forwarding is a
recipient side mechanism, meant to be transparent to senders.

If you introduce a sender's control on forwarding, the difference
between using SUBMIT and relaying through the connection provider's
facility is nullified by adding that facility to the forwarders whitelist.


-------------------------------------------
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, Michael Deutschmann wrote:

> Look at it this way -- there are five kinds of practical forwarding
> problem mitigation:
>
> Crap Receiverside -- Treat all SPF results as if they were the most
> permissive of the actual result and Neutral.
>
> Elite Receiverside -- Use a forwarder whitelist to give a virtual Pass to
> forwarded mail, otherwise apply actual SPF result.
>
> Forwarderside -- Use SRS, or at least sham-SRS (changing the MAIL FROM, but
> making no arrangement to relay bounces).
>
> Crap Senderside -- Write the SPF policy to give the most permissive of the
> correct result (from a G-SPF perspective) and neutral.
>
> Elite Senderside -- Use VERP, the exists mechanism, and a magical DNS
> server.

Excellent summary of correct policies. There is also, however:

Broken Receiverside -- Reject SPF fail regardless of receiver forwarding,
even when the "forwarder" is your own secondary MX (and you think it
is helping block spam because spammers tend to use secondaries first).

Unfortunately, the prevalence of Broken Receiverside is the primary
cause of Crap Senderside.

BTW, PowerDNS provides a pretty clean API for a magical authoritative-only DNS
in your choice of language.

--
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:
> What about forwarders who happened to miss that whitelist?

People with errors in their forwarder whitelist aren't a significant
problem. It's people who don't realize they need one that we need to worry
about.

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

Michael Deutschmann wrote:
>> What about forwarders who happened to miss that whitelist?
>
> People with errors in their forwarder whitelist aren't a significant
> problem. It's people who don't realize they need one that we need to worry
> about.

I, for one. I'd have no idea how to start building one, except if some
forwarder explicitly asked, explaining they have bounces when they
forward to a given address at my MX, and thus need whitelisting.
Symmetrically, if I had bounces when forwarding to a remote MX, I
would first consider changing the sender locally than asking for a
whitelist remotely.



-------------------------------------------
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 09:42 14/07/2009 Tuesday, Alessandro Vesely wrote:
>Michael Deutschmann wrote:
>>>What about forwarders who happened to miss that whitelist?
>>People with errors in their forwarder whitelist aren't a significant
>>problem. It's people who don't realize they need one that we need to worry
>>about.
>
>I, for one. I'd have no idea how to start building one,

you don't your users do {you just sanitize their input}
simply provide an api along with all the others {password change, account cancelation, sender black list, sender whitelist}
{this api can be automated or manual,
ie for small businesses "tell john if you setup forwarding to your address so he can setup the server to accept them"
for big web-mail another set of pages under "setup remote forwarding"}

> except if some forwarder explicitly asked,

replace forwarder with user {as your users contract the forwarders}
and they also will be the irst to notice if its not working

> explaining they have bounces when they forward to a given address at my MX,

explaining how friends/contacts sending to their forwarding address aren't being recieved

> and thus need whitelisting. Symmetrically, if I had bounces when forwarding to a remote MX, I would first consider changing the sender locally than asking for a whitelist remotely.

srs isn't available on many MTA's natively {exchange for instance cannot SRS or forward compliantly with their own sender-id}
{we even offer an SRS rewriting service to our small business customers using exchange because their are so many needing forwarding and so few receivers capable of accepting them, most fortunately just insist their "permanently remote" users get a different mail provider that can/will receive as its less time consuming.}



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