On Mon, Sep 29, 2014 at 05:26:29PM -0300, Hugo Osvaldo Barrera wrote:
> On 2014-09-29 21:35, Gilles Chehade wrote:
> > 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 ?
> >
> >
Ok, so I finally found time to tackle this issue and have come up with a
solution that's ok I guess. Here's a quick explanation.
Multi-line responses are sent using the following format:
5xx-bligh blah
5xx-bloh bleh
5xx final
The final line, without '-', is the one that carries the actual reply so
that smtpd knows what to do with that mail. other lines are informative,
and since they carry no information we don't already have from the final
line, we simply discarded them.
I made a change to that logic so that instead of just discarding them we
now have a reply buffer associated to the client session.
Whenever smtpd enters a new state (MAIL, RCPT, ..) it clears that buffer
and appends all the continuation lines + the final line to it. When this
final line is read, we log the reply buffer.
Since we don't want an evil server messing with our logs by sending some
huge / infinite reply sequence, the reply buffer is limited in size, and
if it overflows, we fallback to logging the final line only.
I also did a bit of work to have the status codes removed from the lines
when concatenating them so that:
5xx-bligh blah
5xx-bloh bleh
5xx final
results in:
5xx-bligh blah blog bleh final
rather than:
5xx-bligh blah5xx-blog bleh5xxfinal
So...
Without this diff, sending mail that is rejected by gmail results in:
relay: PermFail for 3a45d0d114df12c9: session=000000076c353ebb, from=(hidden),
to=(hidden), source=192.168.0.14, relay=173.194.66.26 (we-in-f26.1e100.net),
delay=9s, stat=550 5.1.1
http://support.google.com/mail/bin/answer.py?answer=6596 gf9si1561564wib.42 -
gsmtp
With this diff, it results in:
relay: PermFail for 8e2a0faeec316a03: session=4d039fb37136dd92, from=(hidden),
to=(hidden), rcpt=<->, source=192.168.1.66, relay=74.125.133.26
(74.125.133.26), delay=1s, stat=550-5.1.1 The email account that you tried to
reach does not exist. Please try double-checking the recipient's email address
for typos or unnecessary spaces. Learn more at
http://support.google.com/mail/bin/answer.py?answer=6596 wm4si11934263wjc.14 -
gsmtp
This won't be part of the upcoming minor release, but it will be part of
upcoming snapshots as well as next major release.
--
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]
