On Mon, Sep 29, 2014 at 11:50:41AM -0300, Hugo Osvaldo Barrera wrote:
> On 2014-09-05 19:22, Giovanni Bechis wrote:
> > On 09/01/14 18:53, Hugo Osvaldo Barrera wrote:
> > > 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]"
> > > 
> > I would like to have at maximum 5/6 lines of response on my log to be able 
> > to found if a problem is recurring and which could be the original cause.
> >  Cheers
> >   Giovanni
> > 
> > -- 
> > You received this mail because you are subscribed to [email protected]
> > To unsubscribe, send a mail to: [email protected]
> > 
> 
> It looks like this thread died fast, and nothing was decided.
> Is there any interest on implementing this/making it configurable?
> 
> Would these errors be outputed if smtpd is run with "-v"?
> 
> Cheers,
> 

Ok, what about the following:

- we read n lines, strip their newline and concat them;
- if reply was > n line, we log that output was truncated and needs to
  be analyzed through smtpctl trace

Would that be ok for everyone ?


-- 
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]

Reply via email to