--administrator(_at_)yellowhead(_dot_)com wrote:
We are currently being bombarded by bounced spam messages from a prolific
spammer using not just our domain name, but the FQDN of our mail server. I
don't need to accept messages to this domain, but if I don't, then all
these "USER UNKNOWN" bounces get turned into "mail loops back to me" error
messages to the postmaster. It's too bad that SPF is not more broadly
implemented, as it would quickly terminate this spoofing, but that has
nothing to do with my question.
All these bounces are from legitimate servers (actually most of them are
background servers), and about 1/3 of them terminate their sessions with a
simple QUIT. The other 2/3 terminate with an RSET followed by a QUIT. I am
working on a monitoring program that I intend to arm with SPF, and this
variance in the way sessions are handled has caused me some grief. Does
anyone know why some servers use RSET followed by QUIT, and others just
use QUIT? It seems like a waste of resources to use both.
Here is an idea that doesn't involve SPF, but might be helpful. This is
assuming that the mail is forged blowback and trying to come to your
postmaster address.
1. All usernames except "postmaster" get "user unknown".
2. "postmaster" accepts mail, but not bounces. (You may have to tweak the
rule sets to reject mail from <> to postmaster). This is legitimate since
postmaster sends no mail out, so should not be receiving bounces.
If you do get any mail to postmaster@ and it isn't a bounce, scold the
owner of the sending mail server. They should not notify postmaster by
machine, ever. Postmaster should only be used by real people when
something is wrong, not for ordinary can't-send or has-virus warnings.
Now. It's possible to do something similar to this with SPF, but that's
only useful if the mail coming TO you is also FROM you. If the mail is
from various mailservers, chances are that it's either addressed to you,
but from someone else, or addressed to someone else and supposedly-from
you, bouncing back to you, SPF doesn't help much.
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>