Loading ...
Sorry, an error occurred while loading the content.

Re: Mail in Submit Queue

Expand Messages
  • Bill Cole
    ... 27FC0118B7AF has a null envelope sender because it is a bounce of 3F635118B777. See the 2nd line? ... Many systems play funny games with bounces because
    Message 1 of 6 , May 22, 2013
    • 0 Attachment
      On 22 May 2013, at 7:36, LuKreme wrote:

      > My daily run output (freebsd) sent this message (in part) for today.
      >
      > Mail in submit queue:
      > -Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------
      > 27FC0118B7AF 9831 Tue May 21 14:29:35 MAILER-DAEMON
      > (host eforward3.registrar-servers.com[38.101.213.199] said: 450 4.1.1
      > <Arthritis@...>: Recipient address rejected: unverified
      > address: unknown user: "arthritis@..." (in reply to RCPT TO
      > command))
      > Arthritis@...
      >
      > 45C9A118B7AD 10261 Mon May 20 19:14:02 MAILER-DAEMON
      > (host eforward3.registrar-servers.com[38.101.213.199] said: 450 4.1.1
      > <MedicalBillingandCodingEducation@...>: Recipient
      > address rejected: unverified address: unknown user:
      > "medicalbillingandcodingeducation@..." (in reply to
      > RCPT TO command))
      >
      > MedicalBillingandCodingEducation@...
      >
      > So, I go and sure enough they are in the queue.
      >
      > # postsuper -h 27FC0118B7AF
      > postsuper: 27FC0118B7AF: placed on hold
      > postsuper: Placed on hold: 1 message
      >
      > So I go and check the maillot for yesterday and this is what I find.
      >
      > May 21 14:29:35 mail postfix/cleanup[81455]: 27FC0118B7AF:
      > message-id=<20130521202935.27FC0118B7AF@...>
      > May 21 14:29:35 mail postfix/bounce[81551]: 3F635118B777: sender
      > non-delivery notification: 27FC0118B7AF
      > May 21 14:29:35 mail postfix/qmgr[68570]: 27FC0118B7AF: from=<>,
      > size=9831, nrcpt=1 (queue active)
      > May 21 14:29:38 mail postfix/smtp[81526]: 27FC0118B7AF: host
      > eforward2.registrar-servers.com[209.105.246.195] said: 450 4.1.1
      > <Arthritis@...>: Recipient address rejected: unverified
      > address: unknown user: "arthritis@..." (in reply to RCPT TO
      > command)
      >
      > And now I'm concerned, where did this mail come from, how do I have
      > it, why is there no from?

      27FC0118B7AF has a null envelope sender because it is a bounce of
      3F635118B777. See the 2nd line?

      > Then there are many 450 errors which I guess are the receiver treating
      > unknown user as a transient error which seems odd, but that's well out
      > of my control.

      Many systems play funny games with bounces because they can. Spammers
      like andrite.com and providers who cater to them (registrar-servers.com
      = NameCheap) play particularly irrational games with bounces to slip
      through the cracks in some unwise spam control tactics.

      > The other message appears to be much the same as the first.
      >
      > I'm obviously concerned there's some sir to of backscatter error, or
      > something else that is using my server as some sort of
      > relay/reflector.

      Seems like a backscatter problem. The log should have lines about why
      27FC0118B7AF was asynchronously bounced which will expose the root
      cause.
    • LuKreme
      ... Yes, I see that *now*. Thanks. I think I was tunnel-visioned on the end of the line. ... After looking up the original email I see this is a account that
      Message 2 of 6 , May 23, 2013
      • 0 Attachment
        On 22 May 2013, at 07:07 , "Bill Cole" <postfixlists-070913@...> wrote:
        > On 22 May 2013, at 7:36, LuKreme wrote:
        >> May 21 14:29:35 mail postfix/cleanup[81455]: 27FC0118B7AF: message-id=<20130521202935.27FC0118B7AF@...>
        >> May 21 14:29:35 mail postfix/bounce[81551]: 3F635118B777: sender non-delivery notification: 27FC0118B7AF
        >
        > 27FC0118B7AF has a null envelope sender because it is a bounce of 3F635118B777. See the 2nd line?

        Yes, I see that *now*. Thanks. I think I was tunnel-visioned on the end of the line.

        > Seems like a backscatter problem. The log should have lines about why 27FC0118B7AF was asynchronously bounced which will expose the root cause.

        After looking up the original email I see this is a account that forwards mail to a gmail account, and gmail rejected the forwarded mail because it was spam.

        /var/log/maillog.1.bz2:May 21 14:29:31 mail postfix/smtp[81526]: 3F635118B777: to=<*munged*@...>, orig_to=<*munged*>, relay=gmail-smtp-in.l.google.com[74.125.142.26]:25, delay=1.1, delays=0.26/0.05/0.39/0.45, dsn=5.7.1, status=bounced (host gmail-smtp-in.l.google.com[74.125.142.26] said: 550-5.7.1 [75.148.117.91 12] Our system has detected that this message is 550-5.7.1 likely unsolicited mail. To reduce the amount of spam sent to Gmail, 550-5.7.1 this message has been blocked. Please visit 550-5.7.1 http://support.google.com/mail/bin/answer.py?hl=en&answer=188131 for 550 5.7.1 more information. cl1si4050394igc.54 - gsmtp (in reply to end of DATA command))

        Short of not forwarding to gmail, anything I can do so that this results in dropping the mail (the 'wrong' thing) instead of trying to generate the appropriate bounce (the 'right' thing)?

        --
        Away with him! away with him! he speaks Latin.
      • Bill Cole
        ... I think you could use sender_dependent_default_transport_maps to route bounces to a smtpd that uses nested_header_checks (ewww) to discard messages bearing
        Message 3 of 6 , May 23, 2013
        • 0 Attachment
          On 23 May 2013, at 13:51, LuKreme wrote:

          > On 22 May 2013, at 07:07 , "Bill Cole"
          > <postfixlists-070913@...> wrote:
          >> On 22 May 2013, at 7:36, LuKreme wrote:
          >>> May 21 14:29:35 mail postfix/cleanup[81455]: 27FC0118B7AF:
          >>> message-id=<20130521202935.27FC0118B7AF@...>
          >>> May 21 14:29:35 mail postfix/bounce[81551]: 3F635118B777: sender
          >>> non-delivery notification: 27FC0118B7AF
          >>
          >> 27FC0118B7AF has a null envelope sender because it is a bounce of
          >> 3F635118B777. See the 2nd line?
          >
          > Yes, I see that *now*. Thanks. I think I was tunnel-visioned on the
          > end of the line.
          >
          >> Seems like a backscatter problem. The log should have lines about why
          >> 27FC0118B7AF was asynchronously bounced which will expose the root
          >> cause.
          >
          > After looking up the original email I see this is a account that
          > forwards mail to a gmail account, and gmail rejected the forwarded
          > mail because it was spam.
          >
          > /var/log/maillog.1.bz2:May 21 14:29:31 mail postfix/smtp[81526]:
          > 3F635118B777: to=<*munged*@...>, orig_to=<*munged*>,
          > relay=gmail-smtp-in.l.google.com[74.125.142.26]:25, delay=1.1,
          > delays=0.26/0.05/0.39/0.45, dsn=5.7.1, status=bounced (host
          > gmail-smtp-in.l.google.com[74.125.142.26] said: 550-5.7.1
          > [75.148.117.91 12] Our system has detected that this message is
          > 550-5.7.1 likely unsolicited mail. To reduce the amount of spam sent
          > to Gmail, 550-5.7.1 this message has been blocked. Please visit
          > 550-5.7.1
          > http://support.google.com/mail/bin/answer.py?hl=en&answer=188131 for
          > 550 5.7.1 more information. cl1si4050394igc.54 - gsmtp (in reply to
          > end of DATA command))
          >
          > Short of not forwarding to gmail, anything I can do so that this
          > results in dropping the mail (the 'wrong' thing) instead of trying to
          > generate the appropriate bounce (the 'right' thing)?

          I think you could use sender_dependent_default_transport_maps to route
          bounces to a smtpd that uses nested_header_checks (ewww) to discard
          messages bearing the fingerprint of being the result of a forwarding
          attempt, such as a Delivered-To header containing a local mailbox.

          Implementation details are left as an exercise for the reader
          (bwahahaha...) Note that I have not done the exercise myself, so
          consider this a hand-wave in what seems to be the right direction,
          nothing more.
        • LuKreme
          Bill Cole opined on Thursday 23-May-2013@15:36:24 ... Heh. I’ll pass, I think. You’re the same Bill Cole who used to hang out with me on the SIMS list way
          Message 4 of 6 , May 23, 2013
          • 0 Attachment
            Bill Cole opined on Thursday 23-May-2013@15:36:24
            > On 23 May 2013, at 13:51, LuKreme wrote:
            >
            >> On 22 May 2013, at 07:07 , "Bill Cole" <postfixlists-070913@...> wrote:
            >>
            >> Yes, I see that *now*. Thanks. I think I was tunnel-visioned on the end of the line.
            >>
            >>
            >> After looking up the original email I see this is a account that forwards mail to a gmail account, and gmail rejected the forwarded mail because it was spam.
            >>
            >> /var/log/maillog.1.bz2:May 21 14:29:31 mail postfix/smtp[81526]: 3F635118B777: to=<*munged*@...>, orig_to=<*munged*>,
            >> relay=gmail-smtp-in.l.google.com[74.125.142.26]:25, delay=1.1, delays=0.26/0.05/0.39/0.45, dsn=5.7.1, status=bounced (host gmail-smtp-in.l.google.com[74.125.142.26] said: 550-5.7.1 [75.148.117.91 12] Our system has detected that this message is 550-5.7.1 likely unsolicited mail. To reduce the amount of spam sent to Gmail, 550-5.7.1 this message has been blocked. Please visit 550-5.7.1 http://support.google.com/mail/bin/answer.py?hl=en&answer=188131 for 550 5.7.1 more information. cl1si4050394igc.54 - gsmtp (in reply to end of DATA command))
            >>
            >> Short of not forwarding to gmail, anything I can do so that this results in dropping the mail (the 'wrong' thing) instead of trying to generate the appropriate bounce (the 'right' thing)?
            >
            > I think you could use sender_dependent_default_transport_maps to route bounces to a smtpd that uses nested_header_checks (ewww) to discard messages bearing the fingerprint of being the result of a forwarding attempt, such as a Delivered-To header containing a local mailbox.
            >
            > Implementation details are left as an exercise for the reader (bwahahaha...) Note that I have not done the exercise myself, so consider this a hand-wave in what seems to be the right direction, nothing more.

            Heh. I’ll pass, I think.

            You’re the same Bill Cole who used to hang out with me on the SIMS list way back when Mac OS 8 was cutting edge, right?

            Those were the days.

            --
            Sam, I thought I told you never to play--
          • Bill Cole
            ... [...] ... It shouldn t be hard to do, at least not to the point of doing something reasonable 99% of the time. It could have a real long tail of edge cases
            Message 5 of 6 , May 24, 2013
            • 0 Attachment
              On 23 May 2013, at 22:18, LuKreme wrote:

              > Bill Cole opined on Thursday 23-May-2013@15:36:24
              [...]
              >> I think you could use sender_dependent_default_transport_maps to
              >> route bounces to a smtpd that uses nested_header_checks (ewww) to
              >> discard messages
              >> bearing the fingerprint of being the result of a forwarding attempt,
              >> such as a Delivered-To header containing a local mailbox.
              >>
              >> Implementation details are left as an exercise for the reader
              >> (bwahahaha...) Note that I have not done the exercise myself, so
              >> consider this a hand-wave in what seems to be the right direction,
              >> nothing more.
              >
              > Heh. I’ll pass, I think.

              It shouldn't be hard to do, at least not to the point of doing something
              reasonable 99% of the time. It could have a real long tail of edge cases
              if you have lots of forwarding accounts getting legit messages which
              tickle spam filters, but if you can accept dropping all bounces of
              forwarded mail as a no-exceptions policy it would mostly be a project in
              reading the docs.

              > You’re the same Bill Cole who used to hang out with me on the SIMS
              > list way back when Mac OS 8 was cutting edge, right?

              Caught! I confess to having a diverse and disreputable history of
              bloviating on a wide range of mail software. And last week I had a
              little hands-on with a SIMS system, helping to end its life mercifully.

              > Those were the days.

              Simplicity in an MTA has great nostalgic appeal. On the other hand, at
              that time I was also handcrafting sendmail.cf for sites that could not
              be run on SIMS or anything else as simple. I much prefer wrangling
              Postfix (and a little CGP, and the inescapable but these days always
              trivial Sendmail.)
            Your message has been successfully submitted and would be delivered to recipients shortly.