Re: SPF and bouncing

again i recommend taking this offlist to the email i supplied, without your permission I'm not going to direct mail you

At 15:05 07/04/2012  Saturday, Michael Deutschmann wrote:
>On Sat, 7 Apr 2012, Alessandro Vesely wrote:
>> I'd say no, because of the better-cause-deserving diligence that some
>> organizations put in making sure that the envelope sender is kept
>> unaltered on forwarding to external mailboxes.  That policy is
>> supported by "alias expansion" as standardized by SMTP.
>
>We aren't discussing forwarders, but ordinary SMTP with only one hop
>across the border.
>
>Although the conspiracy is quite relevant to forwarders.  It destroys
>them and is even harsher on SRS forwarders than legacy forwarders.

err? what no it isn't forwarders (especially srs forwarders) are pretty much immune to backscatter complaints
(unless the end user dosn't have them exempted from content filter rejection in which case they should (as we do) fire the customer if he won't/can't.
we/they (and anyone else who provides srs forwarding for users) shouldn't have to destroy our reputation because a user wants to set the filtering our side to be more lax than on his side, he should filter at our reception no-where else.
as a forwarder will never have a non-existant mailbox as a recipient.

>The only sustainable hope for a forwarder is a side deal with the admins
>of the ultimate recipient server to obtain the same super-whitelisting
>(overriding even mailbox diskspace quota and immune to automated
>blacklisting) that backup MXes have.  Then it really doesn't matter what
>the MAIL FROM: is.

ok this is the one time bounces MAY legitimately occur (disk quotas)
but unless the user side is abandoned or badly run it shouldn't be persistent or even a common enough occurrence to cause trouble (also sys-admins are supposed to be aware of these issues to lart/delete the user before these issues happen)
(as far as I am aware no backscatter RBLs consider mailbox full as a listing offence even if to innocent 3rd party due to this)
a well setup forwarder or frontline MX will cache 5xx and 2xx responses for period (thus a 5xx from overquota) will result in 1 bounce every period ONLY) obviously it also extends the period the forwarder or frontline MX rejects incoming mail beyond the time the user has resolved the issue, in our case 15mins as we see most users pickup their mail at this interval.

>I hear some forwarders are actually considering the hack of beginning the
>outgoing transaction simultaneously with the incoming one, so that it
>doesn't respond to the sender->forwarder CR LF '.' CR LF until it has the
>response from the forwarder->recipient transaction.  That would be
>conspiracy-compliant but explicitly not RFC-compliant (RFC 1047, RFC 1123
>section 5.3.3).

I think you might be talking rcpt callout verification, which yes our forwarders and forward MX's do
(it breaks no rfc's it simply (when cache expires an next mail arrives) causes at rcpt time a connection helo>mail from: sender>rcpt to: reciever>quit, and if the response in 2xx caches it and accepts the message if response is 4xx or 5xx caches the entire line and responds to the sender with this till the next cache expiry.