[Mimedefang] Deadline for SPF records *long w/morbid horoscope*

[Kelson Vibber]

At 10:55 AM 8/12/2004, Matthew.van.Eerde at hbinc.com wrote:
>Kelson Vibber wrote:
> > Let's try another ISP-as-MX scenario, this time where the company runs its
> > own mail server as primary MX, but uses the ISP's server as a secondary:
>
>Whoa... stop right there.  If ISPs do this, there's a growing onus to 
>maintain a "valid user" list, even without spam/virus filtering.  The 
>details are up to the ISP to determine - whether they hook up a scheduled 
>feed from the customer (via, say, LDAP) or whether they ask the user to 
>manage valid users via a web interface.

No, you missed the point.  Everyone's been so focused on bounces from mail 
sent to invalid users.

Bad recipients are NOT the only problem!

- Lots of different criteria can cause mail to bounce.
- Some of those criteria (such as spam filters) are hard to keep in sync 
across multiple implementations.
- There are fairly common circumstances under which mail will follow a 
chain of servers, and be rejected somewhere other than the first link.

Here's another one: a simple forwarding address.
1. Message hits forwarder.
2. Forwarder redirects message to real mailbox at another service.*
3. Real mailbox is full, or rejects based on spam filtering.
4. Forwarder generates a bounce.

* In this scenario, it doesn't matter whether the sender is rewritten, 
because we're assuming the real mailbox issues an SMTP reject when the 
forwarder connects.

How do you prevent the bounce from being generated in this instance?


And then there's the problem for which sender verification schemes (not 
just SPF, but the entire class) were actually designed, in which the forged 
message actually reaches a recipient:
         a. Phishing scams
         b. Trojan software (install this patch now!)
         c. Classic Joe-Jobs (i.e. targeted forgeries to tarnish your 
reputation)
         d. Complaints sent to the wrong people (such as your ISP's abuse desk)

If a phisher has to use hotmail.com instead of paypal.com, fewer people are 
going to fall for the scam.  If the "Launder your money now!" message is 
talking about your site but comes from yahoo.com, again it's going to be 
less effective.  If the spammer has to use his own domain name, complaints 
will at least go to the right place instead of cluttering third-party abuse 
desks.

Sure, PGP and S/MIME are probably more elegant solutions.  But if you think 
it's hard getting mail server admins to agree on and implement something 
like SPF, just try convincing every man, woman and child on the Internet to 
digitally sign every piece of outgoing mail!


Kelson Vibber
SpeedGate Communications <www.speed.net>