In <9156B81DAA29204989AD43E88688FAAB013EDA8F(_at_)df-lassie(_dot_)dogfood>
"Harry Katz" <hkatz(_at_)exchange(_dot_)microsoft(_dot_)com> writes:
Greg Connor [mailto:gconnor(_at_)nekodojo(_dot_)org] wrote:
Correct, the sender will get a bounce in this case saying the
message could not be delivered.
That causes two problems:
1. If spoofed mail has been sent through a non-SRS compliant forwarder
(i.e. almost all of them today) then a joe job results. By rejecting
mail at MAIL FROM you are contributing to one of the problems you're
trying to solve.
And the alternative is what? Not doing bounces?
Rejecting during the SMTP session is far better than accepting the
email and then bouncing. However, it is not always possible to reject
email during the SMTP session, which is part of why validating the
RFC2821 MAIL FROM is important.
2. This approach raises the bar considerably for legitimate senders to
be assured their mail is getting delivered. They not only have to know
the email address of the recipients. They also have to know that every
forwarder that every recipient might choose to use has implemented SRS
or some form of rewriting. This will do nothing, to say the least, to
restore confidence in the reliability of email from the perspecive of
legitimate senders.
There are folks that send email.
There are folks that receive email.
In the current state of the world, there are far more emails sent than
people want to receive.
If someone sends email that is wanted by the receiver and it gets
rejected due to a spam check of any form, the receiver will often try
to change the situation.
In the case of forwarders and C-ID/LMAP checks, the receiver generally
knows about that relationship. It is incumbent on mail-admin that
does the C-ID/LMAP checks to get the forwarders to change or to
whitelist them. If the forwarder is a commercial enterprise, they
will almost certainly want to do what they need to do in order to get
their customer's email delivered.
From my experience with SPF, there doesn't appear to be anywhere near
as many forwarders out there as I had expected. There cetainly
appears to be far less email sent through forwarders than, say, sent
from mailing lists that don't use the Sender: header.
So, while we know that we are breaking an existing practice, we need
to as the question "is it worth it?" That is, is the damage done to
the sender's reputation by having their email forged outweigh the
damage done to their reputation by not having all of their email
delivered? This is something individual domain owners need to judge,
but I would say that publishing an SPF record with "-all" in it is a
reasonable thing to do.
How can the forwarder be whitelisted when the forwarder doesn't rewrite?
The forwarder doesn't appear in the MAIL FROM. Only the original sender
does. So you can't base rejection on MAIL FROM.
You can whitelist the forwarder by IP address or the HELO domain.
-wayne