Re: SPF and bouncing

At 02:24 09/05/2012  Wednesday, Michael Deutschmann wrote:
>On Mon, 7 May 2012, alan wrote:
>> ok so basically your wanting to add stuff to spf because you want an easier way to do goldlisting
>> (seems to be the crux here)
>> so your assuming anyone wanting to talk to your goldlisting implementation will
>> choose to use your new spf (if they use batv/verp
>> care to pass your filters
>
>I'm actually more concerned about the outgoing side of the equation.  I
>want to keep it easy for other people to whitelist and greylist *me*.

well then be assured they will have verp aware sender whitelists if they use such
(or they will fail to receive a significant amount of mail and thus be unused) 
(greylisting is a totally different technology and only deals with ips/and retrys)

>To that end, assuming no reform possible in any protocol, I'd rather be
>"RFC-ignorant" and reject <>, than use VERP and tangle up other people's
>sorting of my (non-bounce) mail.

or how bout just accept them and realize that no one is using <> to target you (or anyone else)
(verp is only suggested as a fix IF incoming forged <> becomes a burden)

>But if a standard SPF VERP modifier was added, and there were signs that
>greylist and whitelist using recipient sites were listening for it, then
>my scales might tip away from rejecting <> and towards VERP....

how about as i suggested you dont try and usurp spf for some sort of verp decode protocol
(as said current batv/verp implementations are largely db based and non-trivially reversed)
but instead write/create or convince someone else who equally believes this is useful to write a separate protocol for this
if such a protocol existed then convince batv/verp users to start to use reversible verp

adding such a second protocol (without any thought as to syntax and the myriad ways a decode 'key/algorithim' could be expressed to spf seems like a futile and non-usefull proposal)

as spf provides to reciever's a way to provide
helo+ip > spf > pass fail softfail permerr temperr neutral
mfrom+ip > spf > pass fail softfail permerr temperr neutral

your protocol needs to provide

mfrom > your-protocol > unencoded-sender-address

does this? make it clearer how this is a separate protocol with entirely different inputs/outputs?

>> (ie more so than nether side being informed of the mail dissapearing
>> into the void)
>
>It doesn't have to disappear into the void.  The proper way to handle it
>is to declare that for handoffs from MX to internal mail store, there is
>no such thing as a permanent mail failure.  Smarthosts react to a 5xx or
>prolonged 4xx by generating a bounce (they can avoid backscatter with
>AUTH), but the procedure for an MX should be to place the failed message
>in a special hold queue, only flushed by explicit admin action.
>
>When such a 5xx occurs, the MX automatically sets a flag to start 4xxing
>everything incoming to the failed destination domain, then alerts its own
>admin, who attempts to contact the internal mail store admin to fix the
>configuration problem leading to 5xx.  When the internal mail store admin
>reports the problem is fixed, the MX admin flushes the hold queue, and
>then only after that delivery is complete, releases the 4xx flag.

and how is this 'better' than the standard option of make after internal 5xx generate 1 bounce (as first mail accepted due to cached 2xx) and 5xx all further mail till cleared (due to the same caching)
after internal 4xx , give external 4xx till cleared (if first message accepted due to cached 2xx times out send 1 bounce)
also potentially generate 1 additional bounce every cache expiry and retry

your method seems to rely on a lot of out of protocol and manual intervention.
(which in real world terms means mail broken for days/weeks and neither sender or receiver made aware)
not to mention re-engineering of most current MTA software

subsequent senders are made aware initial one with his message sitting in an un monitored queue is never told

>Yes, this does mean the internal admin can be forced to let a mailbox grow
>into disk space the actual end user never paid for.  My faction of the
>conspiracy is aware of this but doesn't care.

with mine this never happens the user just stops receiving mail, all senders are informed in timely fashion with only a tiny amount of bounces (1 per cache cyle, 1 total if callforwards are used), the admin is encouraged instead to delete users who do not clean up their mailboxes if/when full (as inactive users should be removed not just left as dead letter stores)

>A nice side effect of this hard-handed approach is that it blocks the
>kind of bounces you agree are unacceptable for free.

not really as it means those indefinitely queued forgeries either goto a blackhole or more likely result in a manual mail being sent by admin to try and  notify the sender (delayed and manually sent from non <>)

>Delivery is only truly impossible when the destination address doesn't
>actually exist.  But failing to detect that problem in-transaction is
>just as bad as doing spam filtering late.

err the most common form of mailbox full is admin inaction, (not deleting dead/left/quit/fired/retired employee address')
with current (well setup) systems bounces are the senders first clue, and as already mentioned well setup systems only bounce once (so not an issue for backscatter watchers)

either way a solution like you describe is a total rewrite of software, for this there are already plenty of currently available software solutions for synching mailbox status between frontend and backend (LMTP is designed for this and should be used in these conditions for example)
<http://en.wikipedia.org/wiki/Local_Mail_Transfer_Protocol>http://en.wikipedia.org/wiki/Local_Mail_Transfer_Protocol