At 11:33 AM 1/14/2008 +0100, Alessandro Vesely wrote:
Stuart D. Gathman wrote:
On Sun, 13 Jan 2008, Alessandro Vesely wrote:
I've ended up making a blanket rule - no forwarding to AOL. Ever. For
any reason - enforced by checking for aol.com in the MAIL TO for forwarded
messages by the outgoing mail milter.
Obviously, senders want to maximize the chances that what they send gets
delivered. However, I hadn't thought that one would sacrifice forwarding
to specific domains in order to maximize the sum of its delivery chances.
As an alternative, you may register a domain that you only use for SPF-
compliant forwarding of unfiltered mail. That domain will end up having
the reputation it deserves, i.e. some average of the global spam traffic.
To let recipients make a better classification, you may opt to do vanilla
forwarding for senders that either lack any SPF policy or authorize your
IP explicitly --to achieve the same effect w.r.t. DNSBLs you need to use
a dedicated IP as well.
Doesn't help with AOL. They track reputation by IP (they don't check SPF). I
would need a another IP for forwarding unfiltered mail to AOL - and it would
a waste because it would be very quickly blacklisted.
Thus it becomes apparent that SPF can help saving IPv4 addresses!
(In that respect, it is functionally similar to the "Host" HTTP header
and the "Server Name Indication" TLS extension.)
I mentioned you needed a dedicated IP. If the receiver that feeds your
forwarder is a client of the same DNSBL that blacklists it, that should
make for a good removal argument: it is enough if they blacklist the
original submitter. (AOL is peculiar in that it doesn't publish its
Of course, it is technically unfeasible to forward mail keeping the
original sender's IP address. That is similar to the case where the
original sender's policy doesn't allow the forwarder to keep the same
envelope sender's domain. For both cases, the forwarder's problem is
how to indicate to blacklisters that the responsibility of the message
content should be associated with the original datum. For both cases,
blacklisters may contest the trustworthiness of the Received[-SPF]
headers written by forwarders.
Well, using our new terminology, we should be able to simplify this discussion.
Sender(s) --> Transmitter--> / --> Receiver --> Forwarder(s) --> MDA -->
Border (Stuart) (aol.com)
As I understand it, Stuart is saying that the MDA (aol.com) blacklists his IP
address whenever a Recipient, who asked Stuart to forward his mail, later
clicks "This is Spam" on a piece of that forwarded mail. This blacklisting
then blocks mail from Stuart to other Recipients at aol.com.
Now, the "original submitter" (I assume you mean Sender in our diagram) SHOULD
be the one held responsible for the spam, but that is something that can only
be handled between the Transmitter and Receiver. The Receiver should get the
spam report (not AOL, not SpamCop, not anyone who doesn't know what is going
on). The Receiver should communicate with the Transmitter (not directly with
the Sender) and the Transmitter should take prompt action to eliminate the
problem (zombie Sender, whatever).
The trickier question is what should Stuart do when AOL takes action against
him, based on an error by the Recipient. Cutting off all AOL recipients seems
a bit extreme to me, and certainly worse than letting AOL cut the connection.
AOL should deal with the complaints. Maybe if they hear from their own
customers, they will find a better way to accommodate forwarders.
I don't know AOL's policies, but assuming they don't blacklist senders when
there is only a very small amount of spam leaking through, a less severe
Forwarder's policy might work. Perhaps Stuart could suspend just one Recipient
account on the first spam report. That will ensure the Recipient knows not to
do it again. Maybe the problem is absent-mindedness. The Recipient should
figure out how to segregate the forwarded mail from anything else which he
might report as spam. That may even require setting up a whole new account
just to receive forwarded mail. I've done this with all MDAs that handle my
own mail. Most accounts are free, so its not a big deal.
Sender Policy Framework: http://www.openspf.org
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription:
Powered by Listbox: http://www.listbox.com