Previously we were only checking total size but then silently dropping the
emails ( not on purpose but as result of the long local-part ). So we start
to enforce the limits pre-queueing.
Giving the nature of these messages, I think we will rewrite the
offending address coming from *.bounces.google.com to "<>".
José Borges Ferreira
On Tue, Jul 10, 2018 at 5:45 PM Brandon Long via mailop <firstname.lastname@example.org>
> Long senders are almost always a version of VERP, encoding information
> about where the mail comes from so bounces can be attributed directly.
> When we were writing a different one, we went through several iterations
> including having it case sensitive, to try and keep it shorter. There were
> a lot more servers which failed to maintain the case sensitivity than
> rejected the longer local-part, so since then we've gone with the longer
> Pretty sure these addresses are referencing specific comments in Google
> Outside of some firewalls which enforce the limits, we saw very few
> servers enforcing them. For us, I think we enforce the smtp command line
> limit instead to protect the server.
> Anyways, it's your server, reject away as you wish.
> On Tue, Jul 10, 2018, 8:11 AM Bill Cole <
> mailop-20160...@billmail.scconsult.com> wrote:
>> On 10 Jul 2018, at 8:43 (-0400), David Hofstee wrote:
>> > Hi José,
>> > More do it, but not that many. Some will just clip the local part.
>> In the hierarchy of very wrong mail behaviors, "clipping" a local part
>> is deeper in the muck than using overlong local parts or rejecting them.
>> > On 10 July 2018 at 14:16, Jose Borges Ferreira <undersp...@gmail.com>
>> > wrote:
>> >> I'm getting some notifications from @docos.bounces.google.com that
>> >> have a
>> >> local-part with the following pattern 1234567890123+
>> >> 1234567890123456789012345678-012345678901234567890123456789
>> >> 01.123456....@docos.bounces.google.com.
>> The danger here in "clipping" the address is that no mechanism for doing
>> so is likely to reach a consistently reasonable result. It is clear that
>> there are delimited fields in that local part, it is NOT clear whether
>> any is more or less significant than others. If there is any chance of
>> that address being used as a recipient on future as a consequence of
>> accepting the message for delivery, it is best to just reject it. If
>> it's just an envelope sender, maybe acceptance and delivery (after which
>> the SMTP envelope sender is irrelevant and maybe even gone) isn't
>> Bill Cole
>> b...@scconsult.com or billc...@apache.org
>> (AKA @grumpybozo and many *@billmail.scconsult.com addresses)
>> Currently Seeking Steadier Work: https://linkedin.com/in/billcole
>> mailop mailing list
> mailop mailing list
mailop mailing list