> Greg Connor [mailto:gconnor(_at_)nekodojo(_dot_)org] wrote:
>
>> In general, an MTA should either be an agent for the sender, or an
>> agent for the receiver. Third-party MTAs don't get involved
just on a
>> whim; either the sender or the receiver asked for them to
be involved.
>> If a receiver wants to receive forwarded mail, the
forwarder needs to
>> comply, or they need to make an exception for that forwarder.
Harry wrote:
> But as I noted above, the receiver can't make an exception (i.e.
> whitelist) because the forwarder doesn't appear in the MAIL FROM.
> So that means all forwarders have to rewrite.
From: Pete Resnick [mailto:presnick(_at_)qualcomm(_dot_)com]
No. The receiver must whitelist based either on the IP
address of the forwarder or on the HELO domain. This does
mean that you can't just set up a .forward to a receiving
system that implements MARID checking without the admin of
that system doing such a whitelist entry.
In the future, you could use the ORCPT parameter as the check
if folks would implement it for forwarding.
To go back to your original question, yes, you can reject
mail based on 2821 so long as you are willing to tell your
users "You can't forward to here unless you tell me from
where you're forwarding."
--Harry Katz <hkatz(_at_)exchange(_dot_)microsoft(_dot_)com> wrote:
That's a reasonable position if you're asking users to tell you the
email addresses from where they're forwarding. It's not reasonable if
you're asking end users to supply the IP address or HELO domain of the
forwarder's MTA. It's also not reasonable if you're asking the
receiver's MTA administrator to find and maintain that information --
that won't scale.
trusted-forwarders.org is such a whitelisting service, and it seems to work.
If the forwarder is not doing MAIL FROM rewriting, then even with
whitelisting you can't reject based on 2821 because the forwarded
address doesn't appear in MAIL FROM, only the original sender's address.
I think Pete already answered this one.
No. The receiver must whitelist based either on the IP
address of the forwarder or on the HELO domain. This does
In other words, "whitelisting" doesn't necessarily mean "allow by purported
From: address"
If the forwarder IS doing MAIL FROM rewriting, what precisely is it that
the receiving user is supposed to whitelist? The rewritten address
containing a randomly inserted cookie? The forwarder's entire domain?
Hello, uh, you were asking what needs to be done IF SRS is not used, so
it's going to be a bit confusing if you change the question around after
the answer is given.
But to answer your question, the whitelisting is a workaround for non-SRS
forwarders and their users. It is not needed for SRS forwarders.
Whitelisting does not work for MAIL FROM in either case!
I really wish it were possible to reject reliably on a spoof check of
MAIL FROM, but it just isn't folks. It just isn't.
It's becoming pretty obvious here that you're stating your own personal
opinion and attempting to pass it off as "anything else just is not
reasonable". It's not a productive use of my time to answer endless
questions that are already covered here before, and in SPF FAQ, etc. I
think any further "questions" (really, challenges) about MAIL FROM that
could be answered with pointers to the SPF or DMP FAQ should be replied
with a URL and no further ceremony given.
I'm certainly willing to have a reasonable discussion here, but if you're
going to be evasive, dismissive, or continue to take a condescending tone,
I'm going to choose to focus my time on responding to *sincere* discussion
rather than your style of discussion.
Perhaps you're not being "deliberately" abrasive, but I think if you wanted
to tear this group apart from the inside you're making an admirable start.
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>