Launchpad itself

"entire diff" subscription option can't always work

Bug #139071 reported by Michael Hudson-Doyle
4
Affects Status Importance Assigned to Milestone
Launchpad itself
Fix Released
Medium
Tim Penhey
Launchpad itself 3.0

Bug Description

Currently, one of the diff size options is "send entire diff". This is, to some extent, a lie, as when diffs get really huge, mail servers are going to refuse to carry them (OOPS-619SMS1).

I guess a sane approach is to have a hard limit (defined how, I don't know). Measuring diff size as lines is of course not entirely correlated to diff size in bytes, which is probably what the mail server cares about...

Tangentially, I guess when diffs get too big, we can send codebrowse urls instead.

Tags: email lp-code
Revision history for this message
Steve Alexander (stevea) wrote :

Perhaps the code that sends the diff by email can notice when the mail server says "the mail is too large for me!", and so send a URL instead.

Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :

That would probably be a good practical solution.

It's not a complete solution, because we can't be sure that the first server that sees the mail is the one with the strictest size limits. I don't think we want to start processing bounces to find out which mails haven't been delivered...

Revision history for this message
Tim Penhey (thumper) wrote :

Is 552 an standard error code that we could expect from an SMTP server?

If it is, then we could catch that and send a link without too much of a problem.

Tim Penhey (thumper)
Changed in launchpad-bazaar:
importance: Undecided → Medium
status: New → Confirmed
Revision history for this message
Jonathan Lange (jml) wrote :

+1 to mwh's qualification of Steve's suggestion.

Would sending the diff as an attachment get it through more mail servers?

Revision history for this message
Martin Pool (mbp) wrote :

552 is standard <http://www.greenend.org.uk/rjk/2000/05/21/smtp-replies.html> but there are many broken servers out there, so you can't reply on it.

We cannot rely on the first server rejecting it.

I think we probably need to cap it at some reasonable size (1MB?) if only out of consideration for the final user; many clients will be slow with very large messages.

Aaron Bentley (abentley)
tags: added: email
Tim Penhey (thumper)
Changed in launchpad-code:
assignee: nobody → Tim Penhey (thumper)
milestone: none → 3.0
status: Triaged → In Progress
Tim Penhey (thumper)
Changed in launchpad-code:
status: In Progress → Fix Committed
Tim Penhey (thumper)
Changed in launchpad-code:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.