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 "<>".

Thanks,
José Borges Ferreira

On Tue, Jul 10, 2018 at 5:45 PM Brandon Long via mailop <mailop@mailop.org>
wrote:

> 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
> local-part.
>
> Pretty sure these addresses are referencing specific comments in Google
> docs.
>
> 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.
>
> Brandon
>
> 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
>> harmful.
>>
>> --
>> 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@mailop.org
>> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>>
> _______________________________________________
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
_______________________________________________
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Reply via email to