Re: SPF and bouncing

At 04:55 12/04/2012  Thursday, Michael Deutschmann wrote:
>On Wed, 11 Apr 2012, alan wrote:
>> no spammers need to the forge the from
>
>Most do so, preying upon senders who do not use SPF -all and recipients
>who don't act on SPF Fail.  But others use their own domains, preying on
>recipients who foolishly upscore on SPF Pass alone. (They also use DKIM
>the same way.)
>
>SPF Pass *and* a known sender is a quite strong indicator of non-spam.
>But the known sender is essential.  {SPF Neutral or None, known alleged
>sender} is a much more trustworthy mail stream than {SPF Pass, unknown
>sender}.

first OUT OF CONTEXT

(you claimed of bounces to spammers (assuming a non forged from))
>  Some spammers might find it hiliarous to teergrube you, or endlessly 4xx.

no spammers need to the forge the from
(actually my punctuating and missing y mistake)
no spammers need to, they forge the from

(some spammers don't but thats what ip and domain based RBLs/ are for )

as for receivers that upscore content based on forgery/non-forgery status
A not our problem (were trying to cleanup senders, receivers who want to get more spam we can't force to fix)
B they will learn or drown eventually
C refusing for spf fail is not spam related its forgery related, content isn't the issue sender policy is, the fact it kills a lot of spam is an accidental bonus.
(side policys like giving extra 'spammyness/lack of clue of sender' score for +all, i think is fine still, but ?all is just indicative of a users provider not providing a submission server to the user (like old isps who just allow user outgoing service on port 25 from their ip range only, so their users are forced to use other relays when traveling/abroad, yes it makes them vulnerable to abuse, but no more so than an spf pass for same address (ie a bot on correct ip range sending via same smarthost with [email protected])

as i said before such senders are refusable based on their allowance of forgeries, both the local (spf pass) and remote (spf neutral) as both allowed the sender to stick anything in their envelope-from based on ip (both provide bots service), refusing them (based on ip) will encourage them to cleanup their setup and eventually provide submission servers/authentication/and forgery controll, then once they are clean senders -all/~all spf records.

in cases like above spf pass and known sender is no indication of non-spam, (only indicator that the address [if forged] was forged by a bot on the same badly run isp, why content checks are still needed.

senders should be/are only whitelisted from content checks IF they regularly send content that triggers them that is still wanted. others needn't be

(in fact most freemail accounts tend to be stolen/used by spammers entirely because they know this gets to users who don't content check their 'friends' so this policy only incentivises this theft) 

>> if the mailbox is full the backup MX should be 5xx or 4xx ing the mail
>
>For there to be any point in a backup MX, the backup has to be able to
>accept mail while it has no connectivity to the primary.  It thus cannot
>rely on knowing precisely how full the mailbox is. 

why i said it should cache the result of previous attempt
(ie first attempt that gets a 5xx or 4xx (when issue occours) gets cached for period of time, this and callforwards ensures that a quota issue causes only 1 bounce)
and in real terms today no backup mx is cut off from primary for long or often enough in real terms
nowdays multi mx setups are more to spread the load of edge servers (and all the filtering they must perform at smtp time) so the post filtering load/bandwith on the mailbox server is negligible
for our customers the driving force is so their tiny dsl line dosnt have to take the 99% of connections that end in 5xx, for most others its unlikely to be much different, dialup/isdn and intermittently connected mailbox servers are vanishingly small today, and most do not use smtp as the transport if they exist (domain pop3 in is common and much easier, with a http gui to add/remove stale addresses on the provider/MX side, also works with exchange and fetchmail)

>A system can be engineered that is safe from out-of-disk problems.  While
>in contact, the primary and backup agree on a space reservation the backup
>can use when out of contact.

and this redesign of smtp is achieved how?

>If the reservation runs out, then the backup
>starts 4xxing outside senders.  When contact is reestablished, the backup
>will unload the queue (always suceeding because the space was
>pre-reserved), and attempt to refill its reservation (usually suceeding
>but not if the mailbox is now over the quota promised to the end user.)

or easier, as no redesign of smtp is needed, if i see a customers host being often intermittently unavailable, i phone and suggest they should move to a non smtp delivery method, such as domain-pop3, where they admin the valid recipients list on our side because their system cannot be relied on to be available for callforwards
(btw a callforward fail just causes a 4xx to sender, as our edge servers do not ever accept a mail that may bounce, were their to filter their mail and increase the attack-surface not to reduce sender queues)

>> >In the usual case where the primary does come back eventually,
>> >then it can ETRN
>
>The ETRN is purely in-bailiwick, between the primary MX and the backup MX
>who are configured to use it.  It's never visible on the outside internet.
>ETRN is a standard protocol to do this, but if it didn't exist I'd have
>said "primary MX admin does something like `ssh backup-mx exim -qqf' "
>
>> >and the waiting mail can be on it's way immediately.
>>
>> just as easily achieved
>
>The point is that the recipient's backup MX is likely to know immediately
>when the primary comes up, by explicit administrator action.  The sender's
>smarthost does not.  Eventual delivery depends on the whims of the
>sender retry schedule.

mail delays are less of an issue (if receiver system stability is the cause) than abusing senders and potentially forged 3rd parties by accepting mail that may never get to its destination, then later blackholing or returning bounces (which in turn may never get to the recipient due to their admins dumb filtering), if the messages do ultimately fail.

sorry but the majority of users would gladly put up with occasional delays (and more reliable delivery status information)
over never reliably knowing if/when a message got through, due to 'fake 2xx' and no further information.