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

[Kelson Vibber]

At 06:27 PM 8/11/2004, Jeff Rife wrote:
>it is the responsibility of the MX machine to know what is and is not 
>deliverable.
>
>Again, this completely solves the issue of forged return address bounce 
>e-mails.

Actually, no it doesn't.

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:

1. Spammer targets the backup MX (us), assuming it's less protected.
2. We queue, reject, or discard the message.
3. Mail ends up at customer's primary mail server, which rejects *on 
different criteria*.
4. Customer's server issues an SMTP reject to our server.

At this point, we technically *should* generate a bounce.  The address we 
sent it on to was valid, but the message could not be delivered.  We have 
no way of knowing, short of something SPF-like provided by the apparent 
sender's domain, whether the return address is valid, invalid, or 
valid-but-forged.  On the other hand, if we *did* have that information, we 
could have blocked the mail without even queueing it up for the primary MX.

Now if you run all your MXes yourself, you can make sure they all use the 
same criteria and only reject mail at the border.  But that's a bit more 
difficult when one is in-house and the other belongs to your ISP, who may 
not even be running the same mail server software as you, never mind the 
same filtering software.


And then there's the scenario in which the forged message makes it through 
to a valid address, someone reads it and fires off a complaint to the 
person they think sent it...


Kelson Vibber
SpeedGate Communications <www.speed.net>