-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Michael Deutschmann wrote:
> I'd like to put my TENBOX/E proposal back on the table, with a few
> changes.
>
> First, I'm changing the "marketing" to be more a whitelisting
> enhancement with many uses, instead of just a solution to the
> forwarding problem.
>
> [... revamped TENBOX/E proposal ...]
This seems like a clever idea, however I seriously doubt forwarders would
be willing to implement an SMTP/AUTH extension.
Don't get me wrong, I really appreciate your effort. This is a tough nut
to crack. However, as long as a proposed solution takes even just nearly
as much work to implement as sender rewriting it's just as dead-on-
arrival. :-(
However, here's another idea how forwarders could identify themselves.
Suppose a new SPF modifier named "i-am=" that works exactly like
"redirect=", with one addition: the modifier's argument, for example
"forwarder.org", can be considered an additional authenticated identity by
the receiver if SPF evaluation passes for that domain. The receiver can
then use that additional identity to whitelist the sender.
For example, a forwarder says: HELO mta02.forwarder.org
The receiver checks "mta02.forwarder.org" for an SPF record, which yields
"v=spf1 i-am=forwarder.org redirect=forwarder.org"
The receiver finds "i-am=" and ignores "redirect=" (which is there just in
case the receiver doesn't implement the "i-am=" modifier).
They then check "forwarder.org" for an SPF record, which yields
"v=spf1 a:mta01.forwarder.org a:mta02.forwarder.org -all"
The forwarder's IP address matches the SPF record, so the HELO SPF check
passes and the receiver also has authenticated "forwarder.org" as an
additional sender identity (also with a HELO scope), which they can
compare against their HELO whitelist.
Works for mailing lists as well. More importantly, it doesn't require
forwarders to implement any new SMTP magic. All they have to do is
publish some new SPF records in DNS.
(I could have named the modifier "cname=" instead. That would have been a
nice analogy but would have confused the hell out of DNS experts.
And, before anyone wonders: yes, the redirection behavior of "i-am=" is
essential because the authority over whether the specified identity is
legitimate for the sender's IP address MUST be delegated to the owner of
the identity, i.e. the admin of the identity's DNS zone. The common SPF
principle.)
Anyway, perhaps I'm just in a destructive mode today, so please consider
this posting of mine a counter-proposal rather than a dismissal of yours.
Now on to the odds'n'ends:
> I'm now thinking my Sham-SRS idea is the better approach to the
> forwarding problem *as caused by SPF*, however forwarder whitelisting
> is still a necessary idea. Sham-SRS protects the forwarder from SPF
> and post-transaction bounces, but not in-transaction rejections.
Why do forwarders need to be protected from in-transaction rejections?
> 2. DSNs in a goldlisting universe:
>
> One possible endgame in the spam wars is universal goldlisting,
> combined with SPF. Goldlisting is the practice of configuring one's
> mail system to reject all mail by default, only relenting when the MAIL
> FROM: address is on a whitelist.
(This was once called AGUPI (assumed guilty until proven innocent) by Meng
Weng "SPF" Wong.)
> In such a universe, bounce messages will never work, as to prevent mail
> loops, they always have a MAIL FROM of <>. SPF cannot defend this
> address, so spammers would resort to it if goldlisters allowed it.
>
> TENBOX/E comes to the rescue here, by allowing the bounce to be marked
> with the address that failed:
>
> So if Ralph's mailbox is full, a bounce to this message:
> MAIL FROM: <sarah@example.com>
> RCPT TO: <ralph@example.net>
>
> comes as:
> MAIL FROM: <> AUTH=ralph@example.net
> RCPT TO: <sarah@example.com>
>
> and reaches her even if she is using goldlisting.
I understand that this use case is served nicely by your revamped TENBOX/E
proposal, but I don't think _we_ need to care about this use case and it
barely justifies the implementation effort required by your proposal,
especially as it can be solved by something as simple as:
MAIL FROM:<ralph@example.net:bounce> (or <ralph@example.net.bounce>)
RCPT TO:<sarah@example.com>
> 4. Mitigation of ordinary-user VERPing (eg: SES, BATV):
>
> Some users seek to use a form of VERP to protect themselves from
> backscatter, accepting only direct mail to their principal address, and
> directing the bounces to constantly-changing addresses.
>
> Unless the receiving MTA has ad-hoc knowledge of how to derive the
> principal address from the VERPed address, whitelisting and greylisting
> are broken, or at least degraded to operating on entire domains instead
> of mailboxes.
>
> TENBOX/E allows whitelisting and VERP to coexist, since the SWK can
> always be the principal address. An exchange of messages might go:
>
> MAIL FROM: <sarah+32823667@example.com> AUTH=sarah@example.com
> RCPT TO: <ralph@example.org>
Of course this only helps if the receiver has implemented TENBOX/E. Do
you expect everyone who has implemented greylisting to also implement
that?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHhDbNwL7PKlBZWjsRAixsAJ9SUWDzXYoQ/jjB1PqYKVen21hlZgCeIqy2
4j5l4n490VUZtqbBzPrKuBg=
=QXXm
-----END PGP SIGNATURE-----
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=83480793-5fd58a
Powered by Listbox: http://www.listbox.com
Hash: SHA1
Michael Deutschmann wrote:
> I'd like to put my TENBOX/E proposal back on the table, with a few
> changes.
>
> First, I'm changing the "marketing" to be more a whitelisting
> enhancement with many uses, instead of just a solution to the
> forwarding problem.
>
> [... revamped TENBOX/E proposal ...]
This seems like a clever idea, however I seriously doubt forwarders would
be willing to implement an SMTP/AUTH extension.
Don't get me wrong, I really appreciate your effort. This is a tough nut
to crack. However, as long as a proposed solution takes even just nearly
as much work to implement as sender rewriting it's just as dead-on-
arrival. :-(
However, here's another idea how forwarders could identify themselves.
Suppose a new SPF modifier named "i-am=" that works exactly like
"redirect=", with one addition: the modifier's argument, for example
"forwarder.org", can be considered an additional authenticated identity by
the receiver if SPF evaluation passes for that domain. The receiver can
then use that additional identity to whitelist the sender.
For example, a forwarder says: HELO mta02.forwarder.org
The receiver checks "mta02.forwarder.org" for an SPF record, which yields
"v=spf1 i-am=forwarder.org redirect=forwarder.org"
The receiver finds "i-am=" and ignores "redirect=" (which is there just in
case the receiver doesn't implement the "i-am=" modifier).
They then check "forwarder.org" for an SPF record, which yields
"v=spf1 a:mta01.forwarder.org a:mta02.forwarder.org -all"
The forwarder's IP address matches the SPF record, so the HELO SPF check
passes and the receiver also has authenticated "forwarder.org" as an
additional sender identity (also with a HELO scope), which they can
compare against their HELO whitelist.
Works for mailing lists as well. More importantly, it doesn't require
forwarders to implement any new SMTP magic. All they have to do is
publish some new SPF records in DNS.
(I could have named the modifier "cname=" instead. That would have been a
nice analogy but would have confused the hell out of DNS experts.
And, before anyone wonders: yes, the redirection behavior of "i-am=" is
essential because the authority over whether the specified identity is
legitimate for the sender's IP address MUST be delegated to the owner of
the identity, i.e. the admin of the identity's DNS zone. The common SPF
principle.)
Anyway, perhaps I'm just in a destructive mode today, so please consider
this posting of mine a counter-proposal rather than a dismissal of yours.
Now on to the odds'n'ends:
> I'm now thinking my Sham-SRS idea is the better approach to the
> forwarding problem *as caused by SPF*, however forwarder whitelisting
> is still a necessary idea. Sham-SRS protects the forwarder from SPF
> and post-transaction bounces, but not in-transaction rejections.
Why do forwarders need to be protected from in-transaction rejections?
> 2. DSNs in a goldlisting universe:
>
> One possible endgame in the spam wars is universal goldlisting,
> combined with SPF. Goldlisting is the practice of configuring one's
> mail system to reject all mail by default, only relenting when the MAIL
> FROM: address is on a whitelist.
(This was once called AGUPI (assumed guilty until proven innocent) by Meng
Weng "SPF" Wong.)
> In such a universe, bounce messages will never work, as to prevent mail
> loops, they always have a MAIL FROM of <>. SPF cannot defend this
> address, so spammers would resort to it if goldlisters allowed it.
>
> TENBOX/E comes to the rescue here, by allowing the bounce to be marked
> with the address that failed:
>
> So if Ralph's mailbox is full, a bounce to this message:
> MAIL FROM: <sarah@example.com>
> RCPT TO: <ralph@example.net>
>
> comes as:
> MAIL FROM: <> AUTH=ralph@example.net
> RCPT TO: <sarah@example.com>
>
> and reaches her even if she is using goldlisting.
I understand that this use case is served nicely by your revamped TENBOX/E
proposal, but I don't think _we_ need to care about this use case and it
barely justifies the implementation effort required by your proposal,
especially as it can be solved by something as simple as:
MAIL FROM:<ralph@example.net:bounce> (or <ralph@example.net.bounce>)
RCPT TO:<sarah@example.com>
> 4. Mitigation of ordinary-user VERPing (eg: SES, BATV):
>
> Some users seek to use a form of VERP to protect themselves from
> backscatter, accepting only direct mail to their principal address, and
> directing the bounces to constantly-changing addresses.
>
> Unless the receiving MTA has ad-hoc knowledge of how to derive the
> principal address from the VERPed address, whitelisting and greylisting
> are broken, or at least degraded to operating on entire domains instead
> of mailboxes.
>
> TENBOX/E allows whitelisting and VERP to coexist, since the SWK can
> always be the principal address. An exchange of messages might go:
>
> MAIL FROM: <sarah+32823667@example.com> AUTH=sarah@example.com
> RCPT TO: <ralph@example.org>
Of course this only helps if the receiver has implemented TENBOX/E. Do
you expect everyone who has implemented greylisting to also implement
that?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHhDbNwL7PKlBZWjsRAixsAJ9SUWDzXYoQ/jjB1PqYKVen21hlZgCeIqy2
4j5l4n490VUZtqbBzPrKuBg=
=QXXm
-----END PGP SIGNATURE-----
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=83480793-5fd58a
Powered by Listbox: http://www.listbox.com