[Mimedefang] Deadline for SPF records *long w/morbid horoscope*
Kelson Vibber
kelson at speed.net
Thu Aug 12 13:14:33 EDT 2004
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>
More information about the MIMEDefang
mailing list