On 2014-09-01 11:46, Gilles Chehade wrote: > On Sat, Aug 23, 2014 at 12:28:00PM -0300, Hugo Osvaldo Barrera wrote: > > On 2014-08-22 18:32, Giovanni Bechis wrote: > > > On 08/22/14 14:30, Hugo Osvaldo Barrera wrote: > > > > I recently had some messages bounce from gmail.com. I went up to their > > > > forums > > > > to ask what's up, and on the replies, it was pointed out to my that > > > > gsmtpd > > > > actually sends a rather verbose explanation message when it bounces > > > > messages > > > > (eg: if it's spam, invalid return address, blacklisted address, etc). > > > > > > > > Here's the thread were this was pointed to me. I'm guessing that > > > > sending an > > > > email from a non-static IP range is enough to trigger a bounce > > > > harmelessly: > > > > https://productforums.google.com/forum/#!msg/gmail/SQQAbew5tfE/-ue8aO07sf8J > > > > > > > > Can somebody confirm if these explanations are being dropped by smtpd, > > > > if > > > > they're non-standard, or what's going on? > > > > > > > gmail warnings are splitted in two or more lines and smtpd logs only one > > > of them. > > > See https://github.com/OpenSMTPD/OpenSMTPD/issues/365 for details. > > > Cheers > > > Giovanni > > > > > > -- > > > You received this mail because you are subscribed to [email protected] > > > To unsubscribe, send a mail to: [email protected] > > > > > > > Looks like the devs were expecting this to make it to the list and it did > > not. > > Can we bring that up now? Are there any downsides to implementing this? > > > > Yes, we were waiting for the discussion to come up. > > There's a downside to implementing this: > > Imagine you create an account for me on your server. > I then decide to go rogue and setup a remote MX which will reply with > a HUGE response, say 1000s of lines. > > We need to log atomically so: > > a- log line can't be written until we're done reading response; > b- session needs to remember every line of the response until done reading; >
Can't we not-log all of it, but keep the message and send it to the original sender? The logs could be something like: "550 Error... [25 more lines trimmed]" While the sender of the original email get the bounce email with the entire content (all 25 lines in the above example". > > This leads to some issues: > > First, it means that we need to buffer data at the session level. > That amount of data is unknown and if I'm an asshole, I will send tons > of outgoing mails to my rogue server so that there are tons of sessions > buffering tons of data. > Doesn't something similar happen when emails are received? Can't we deal with this in a similar way? > Then, do we really want to log the entire response ? No, I'd suggest trimming it by default. Or a knob to configure this (though that sounds like more work, and, personally, I don't care about logging it. As long as the sender gets the full error, it's enough). > Every time I will send a mail to one recipient, it will fill your logs > with thousands of lines. Without even considering the speed at which I > can amplify your logs filling, what worries me is that it can turn log > files into unreadable garbage where one useful information is lost in > a heap of useless logs. > > > I understand the problem, I also face it daily but logging all is not > the way to go. We need to find a proper balance, let the discussion > begin ;-) > > -- > Gilles Chehade > > https://www.poolp.org @poolpOrg > > -- > You received this mail because you are subscribed to [email protected] > To unsubscribe, send a mail to: [email protected] > To add this up: I believe that the best is to log only a single line (and mention "timmed N lines"), but return the entire error to the sender. Maybe the last bit can be configurable as well? -- Hugo Osvaldo Barrera A: Because we read from top to bottom, left to right. Q: Why should I start my reply below the quoted text?
pgpacHGpMhlVK.pgp
Description: PGP signature
