-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Frank Ellermann wrote:
Julian Mehnle wrote:
If the sender identity has failed an authentication check (SPF or other
means), the bounce is misdirected.
Therefore "misdirected" is defined by e.g. a SPF FAIL policy.
I didn't say "if and only if", just "if".
The one and only useful definition of "misdirected bounce" is "bounce that
goes to any address other than the _real_ sender's one".
But of course, in practice this cannot be determined unless some
authentication check is performed on the alleged sender address.
If no check has been performed on the sender identity, it _might_ be
authentic, but sending a bounce would be grossly negligent due to the
identity's unverified nature.
Rejecting mail to non-existent or over-quota users is simply SMTP.
Are you perhaps mixing up "reject" and "bounce" here? It isn't necessary
to generate bounces for non-existent or over-quota mailboxes, you can very
well reject those right during the SMTP transaction.
And reporting corresponding bounces as "misdirected" without a say SPF
FAIL policy is clueless. That's exactly what SpamCop allows,
- From my understanding SpamCop allows misdirected bounces to be reported as
spam, based on the above definition of "misdirected". A sender
authentication check need not have been performed (and failed) on a bounce
in order for it to be allowed to be reported as spam, as long as you were
not the _real_ sender of the message that bounced.
I cannot see any other valid interpretation of the stated SpamCop reporting
policy.
and as I said it's dubious, because it indirectly propagates the easy way
"kill silently" instead of publishing / checking SPF FAIL policies.
Well, from our (SPF's) standpoint it is not as stringent as we might wish,
but from a misdirected bounce victim's standpoint, allowing bounces to be
reported, even though they did not formally fail a sender authentication
check, is more useful because it discourages ISPs from sending bounces not
only to _known-bad_ sender addresses but also to _unverified_ addresses.
Which IMO is the right thing to do. Bounces must not be sent to
unverified addresses.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQFCiN04wL7PKlBZWjsRAj+UAKD5Pf8sx/YIWbMCSS9Kbinc9Tz0agCfSaAx
KluqxnXWgzwPOrfsvZvRTbo=
=1bg/
-----END PGP SIGNATURE-----