bug#30347: smtpmail.el doesn't retry with authentication when greylisting is used

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

bug#30347: smtpmail.el doesn't retry with authentication when greylisting is used

Rainer Orth-2
I've long been dealing with the following problem: I'm using GNU Emacs
(current 26.0.91, but the problem has existed for a long time before
that) and Gnus to send mail.  The relaying MTA uses greylisting when
receiving mail for local accounts without authentication, but
smtpmail.el cannot deal with the resulting temporary SMTP codes.  I'd
expect that it would retry with authentication, but doesn't.

I've used the following snippet to fix this.  Perhaps this (or something
similar) can be used to fix this issue?

Thanks.
        Rainer

--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University



--- - 2018-02-04 01:21:02.374212479 +0000
+++ /tmp/smtpmail.el 2018-02-04 01:20:44.340497887 +0000
@@ -838,8 +838,9 @@
  ((and auth-mechanisms
        (not ask-for-password)
        (integerp (car result))
-       (>= (car result) 550)
-       (<= (car result) 554))
+       (or (and (>= (car result) 550)
+ (<= (car result) 554))
+   (eq (car result) 450)))
   ;; We got a "550 relay not permitted" (or the like),
   ;; and the server accepts credentials, so we try
   ;; again, but ask for a password first.
Reply | Threaded
Open this post in threaded view
|

bug#30347: smtpmail.el doesn't retry with authentication when greylisting is used

Lars Ingebrigtsen
Rainer Orth <[hidden email]> writes:

> I've long been dealing with the following problem: I'm using GNU Emacs
> (current 26.0.91, but the problem has existed for a long time before
> that) and Gnus to send mail.  The relaying MTA uses greylisting when
> receiving mail for local accounts without authentication, but
> smtpmail.el cannot deal with the resulting temporary SMTP codes.  I'd
> expect that it would retry with authentication, but doesn't.
>
> I've used the following snippet to fix this.  Perhaps this (or something
> similar) can be used to fix this issue?

Hm...  Well, the SMTP error message you're getting is "450, Requested
mail action not taken: mailbox unavailable."?  Retrying with a password
seems a bit odd in that instance.  On the other hand, if this is the
common way for SMTP servers to say that "we're greylisting; log in
first" then it would be OK anyway.

But is it?  :-)

--
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



Reply | Threaded
Open this post in threaded view
|

bug#30347: smtpmail.el doesn't retry with authentication when greylisting is used

Robert Pluim
Lars Ingebrigtsen <[hidden email]> writes:

> Rainer Orth <[hidden email]> writes:
>
>> I've long been dealing with the following problem: I'm using GNU Emacs
>> (current 26.0.91, but the problem has existed for a long time before
>> that) and Gnus to send mail.  The relaying MTA uses greylisting when
>> receiving mail for local accounts without authentication, but
>> smtpmail.el cannot deal with the resulting temporary SMTP codes.  I'd
>> expect that it would retry with authentication, but doesn't.
>>
>> I've used the following snippet to fix this.  Perhaps this (or something
>> similar) can be used to fix this issue?
>
> Hm...  Well, the SMTP error message you're getting is "450, Requested
> mail action not taken: mailbox unavailable."?  Retrying with a password
> seems a bit odd in that instance.  On the other hand, if this is the
> common way for SMTP servers to say that "we're greylisting; log in
> first" then it would be OK anyway.
>
> But is it?  :-)

Itʼs one of the ways. Some return 451 instead. Some 421. Itʼs all very
fuzzy :-)

Oh, and thereʼs an official 'authentication is required' code whose
value escapes me for the moment.

BTW, if emacs has credentials for the connection itʼs making, would it
not make sense to attempt authentication before delivery?

Robert



Reply | Threaded
Open this post in threaded view
|

bug#30347: smtpmail.el doesn't retry with authentication when greylisting is used

Lars Ingebrigtsen
Robert Pluim <[hidden email]> writes:

> Itʼs one of the ways. Some return 451 instead. Some 421. Itʼs all very
> fuzzy :-)
>
> Oh, and thereʼs an official 'authentication is required' code whose
> value escapes me for the moment.

Yeah, smtpmail just uses the "relay not permitted" codes to guess that
it's supposed to try again, which aren't exactly official, either.  So
adding 450/451/421, too, probably won't break anything.

> BTW, if emacs has credentials for the connection itʼs making, would it
> not make sense to attempt authentication before delivery?

You'd think so...  But this might lead to some annoyances in that people
have password-protected their password store, and will now be prompted
for that password even if the SMTP server doesn't require a password.

If you see what I mean.  :-)

So I'm not sure that change would be welcomed by everybody.

--
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



Reply | Threaded
Open this post in threaded view
|

bug#30347: smtpmail.el doesn't retry with authentication when greylisting is used

Robert Pluim
Lars Ingebrigtsen <[hidden email]> writes:

> Robert Pluim <[hidden email]> writes:
>
>> Itʼs one of the ways. Some return 451 instead. Some 421. Itʼs all very
>> fuzzy :-)
>>
>> Oh, and thereʼs an official 'authentication is required' code whose
>> value escapes me for the moment.
>
> Yeah, smtpmail just uses the "relay not permitted" codes to guess that
> it's supposed to try again, which aren't exactly official, either.  So
> adding 450/451/421, too, probably won't break anything.
>

OK

>> BTW, if emacs has credentials for the connection itʼs making, would it
>> not make sense to attempt authentication before delivery?
>
> You'd think so...  But this might lead to some annoyances in that people
> have password-protected their password store, and will now be prompted
> for that password even if the SMTP server doesn't require a password.
>
> If you see what I mean.  :-)
>

Iʼm not sure I follow: the user has a matching machine in authinfo or
wherever they keep their passwords, and the SMTP server advertizes
AUTH support. Why would we not attempt authentication?

> So I'm not sure that change would be welcomed by everybody.

Thatʼs true. What we have now works for me :-)



Reply | Threaded
Open this post in threaded view
|

bug#30347: smtpmail.el doesn't retry with authentication when greylisting is used

Lars Ingebrigtsen
Robert Pluim <[hidden email]> writes:

> Iʼm not sure I follow: the user has a matching machine in authinfo or
> wherever they keep their passwords, and the SMTP server advertizes
> AUTH support. Why would we not attempt authentication?

Because Emacs doesn't know that the user has a password entry in
~/.authinfo.gpg until the user has type the password.  (If the user is
using password-protected ~/.authinfo files without a password agent,
that is.)

Since most SMTP is still unauthorised, "opportunistic" password sending
may not be welcome.

--
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



Reply | Threaded
Open this post in threaded view
|

bug#30347: smtpmail.el doesn't retry with authentication when greylisting is used

Robert Pluim
Lars Ingebrigtsen <[hidden email]> writes:

> Robert Pluim <[hidden email]> writes:
>
>> Iʼm not sure I follow: the user has a matching machine in authinfo or
>> wherever they keep their passwords, and the SMTP server advertizes
>> AUTH support. Why would we not attempt authentication?
>
> Because Emacs doesn't know that the user has a password entry in
> ~/.authinfo.gpg until the user has type the password.  (If the user is
> using password-protected ~/.authinfo files without a password agent,
> that is.)
>

Ah, people who like typing passwords all the time. I see your point, though.

> Since most SMTP is still unauthorised, "opportunistic" password sending
> may not be welcome.

True, unfortunately, much like SMTP/TLS is sadly underused.