> This seems like an odd place to raise this, but ok.
Thanks for replying, Brandon.
Does it make it a better place if I explain that I was writing as a
mail service operator? When we migrated our in-house mail service to
Google our customer service people were keen that we should continue
to log all mail in and out of the University. Because of local
address rewriting rules we needed to use an outbound gateway anyway,
but we also set up receiving routing so that all mail delivered to our
users' mailboxes was delivered to a local server for logging and then
discarding.
Twice a day we generate reports from the log files of big senders,
suspicious subjects, etc. which are sent to the customer service
people. They add addresses to the domain wide blocked sender list if
they see fit. But the only address they have to go on in the log
files is the envelope sender address -- they can't see the From:
address in the message headers.
(As the need for rewriting addresses has been eliminated, we plan to
turn off the outbound gateway but we will continue to log sent mail by
turning on sending routing.)
Richard
> Yes, the blocked sender could be applied to both, I'm not sure if/why it
> wasn't done that way.
>
> That said, I actually think if you're going to check one, then it's the
> RFC5322.From address which is the more logical choice. It's also the more
> user visible choice.
>
> In many instances, messages are sent with VERP like RFC5321.From addresses,
> in the case of most mailing list software and commercial marketing mail, not
> to mention several forwarding systems.
>
> In the case of spam, I imagine that both the RFC5322.From and RFC5321.From
> are highly variable, we don't expect blocked senders to be used for the type
> of spam which mutates in an attempt to evade spam filters. In general,
> playing whack-a-mole using filters or blocked senders for the worst type of
> spam is a fool's errand, you're much better off using the report spam
> feature and letting our systems handle it.
>
> As for the case where you only want to block the RFC5321.From and not the
> RFC5322.From, making the user have to choose which of the addresses to block
> seems poor, and blocking the RFC5321.From only seems unlikely to make sense
> to users either.
>
> Brandon
>
> On Wed, Jan 4, 2017 at 3:30 AM, Richard Gilbert <r.gilb...@sheffield.ac.uk>
> wrote:
>>
>> I have become aware that the Google blocked senders list is only
>> applied to the From: address, and that we cannot use it to block an
>> envelope sender address. Is it just me who finds this surprising
>> (especially given its name)? Why not check both? It seems illogical
>> to accept a message from an envelope sender address which is in the
>> list. Am I wrong in thinking that in the case of spam the From:
>> address is more variable than the envelope sender? There will be
>> cases where we want to block an envelope sender address but unable to
>> block the (different) From: address because it is used by legitimate
>> mail.
>>
>> --
>> Richard Gilbert
>> Corporate Information and Computing Services
>> University of Sheffield, Sheffield, S10 2FN, UK
>> Phone: +44 114 222 3028
>>
>> ___
>> mailop mailing list
>> mailop@mailop.org
>> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>
--
Richard Gilbert
Corporate Information and Computing Services
University of Sheffield, Sheffield, S10 2FN, UK
Phone: +44 114 222 3028
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
