Thread View: pl.comp.mail.mta
2 messages
2 total messages
Started by q0o
Wed, 06 May 2020 10:04
Postfix/smtpd i fetchmail - bład 501 związany z "CR LF spacja" w wartości nagłówka "Return-Path"
Author: q0o
Date: Wed, 06 May 2020 10:04
Date: Wed, 06 May 2020 10:04
94 lines
5976 bytes
5976 bytes
Witam,
Jako, że z e-maili korzystam na co dzień (a lubię wiedzieć jak działają
technologie, z którym korzystam), postanowiłem zobaczyć, jak to wygląda
od drugiej strony i założyć własny serwer pocztowy.
Jakiś czas temu zająłem się kwestią fetchmaila, z którego korzystam, aby
móc pobierać wiadomości z zewnętrznych skrzynek pocztowych na lokalne
konto, zlokalizowane na moim serwerze. Natknąłem się jednak na problem z
pobieraniem niektórych e-maili, pochodzących z raczej szeroko znanych
usług (więc - jak przypuszczam - z działających prawidłowo serwerów
pocztowych).
Przy dostarczaniu wspomnianych wiadomości z fetchmaila zwracany jest
błąd "501 5.1.7 Bad sender address syntax".
Analizując nagłówki tego typu "problematycznych" wiadomości powtarza
jedna kwestia - posiadają one w wartości nagłówka "Return-Path", po 2
znakach nowej linii (CR LF) dodatkową spację, przykładowo:
...
Return-Path: <01000171e5ba5a76-8fcd01c1-f182-4d95-985d-bfdde77d05eb-000000@m
ail.crowdin.com>
...
Czyli szesnastkowo (końcówka wartości, problematyczne znaki zaznaczyłem
nawiasami klamrowymi {}):
30 30 40 6D{0D 0A 20}61 69 6C 2E 63 72 6F 77 64 69 6E 2E 63 6F 6D 3E
0 0 @ m CR LF a i l . c r o w d i n . c o m >
Log postfixa z trybu szczegółowego zapisywania logów (opcja
"debug_peer_list"):
mail | Apr 30 13:56:02 mail postfix/smtpd[1556]: <
localhost[127.0.0.1]: MAIL
FROM:<01000171e5ba5a76-8fcd01c1-f182-4d95-985d-bfdde77d05eb@m
mail | Apr 30 13:56:02 mail postfix/smtpd[1556]: >
localhost[127.0.0.1]: 501 5.1.7 Bad sender address syntax
mail | Apr 30 13:56:02 mail postfix/smtpd[1556]:
watchdog_pat: 0x55815ba4fa70
mail | Apr 30 13:56:02 mail postfix/smtpd[1556]: <
localhost[127.0.0.1]: ail.crowdin.com> SIZE=9287
mail | Apr 30 13:56:02 mail postfix/smtpd[1556]:
match_string: smtpd_forbidden_commands: ail.crowdin.com> ~? connect
mail | Apr 30 13:56:02 mail postfix/smtpd[1556]:
match_string: smtpd_forbidden_commands: ail.crowdin.com> ~? get
mail | Apr 30 13:56:02 mail postfix/smtpd[1556]:
match_string: smtpd_forbidden_commands: ail.crowdin.com> ~? post
mail | Apr 30 13:56:02 mail postfix/smtpd[1556]:
match_list_match: ail.crowdin.com>: no match
mail | Apr 30 13:56:02 mail postfix/smtpd[1556]: report
unknown command to all milters
mail | Apr 30 13:56:02 mail postfix/smtpd[1556]:
milter8_unknown_event: milter inet:localhost:8891: unknown command:
ail.crowdin.com>
mail | Apr 30 13:56:02 mail postfix/smtpd[1556]: event:
SMFIC_UNKNOWN; macros: (none)
mail | Apr 30 13:56:02 mail postfix/smtpd[1556]:
skipping event SMFIC_UNKNOWN for milter inet:localhost:8891
mail | Apr 30 13:56:02 mail postfix/smtpd[1556]:
milter8_unknown_event: skip milter inet:localhost:8893
mail | Apr 30 13:56:02 mail postfix/smtpd[1556]: >
localhost[127.0.0.1]: 502 5.5.2 Error: command not recognized
mail | Apr 30 13:56:02 mail postfix/smtpd[1556]:
watchdog_pat: 0x55815ba4fa70
mail | Apr 30 13:56:02 mail fetchmail[1551]: reading
message username@o2.pl@poczta.o2.pl:1 of 1 (9287 octets) (log message
incomplete)
mail | Apr 30 13:56:02 mail fetchmail[1551]: SMTP
error: 501 5.1.7 Bad sender address syntax
mail | Apr 30 13:56:02 mail fetchmail[1551]: not flushed
mail | Apr 30 13:56:02 mail postfix/smtpd[1556]: <
localhost[127.0.0.1]: RSET
mail | Apr 30 13:56:02 mail postfix/smtpd[1556]: >
localhost[127.0.0.1]: 250 2.0.0 Ok
mail | Apr 30 13:56:02 mail postfix/smtpd[1556]:
watchdog_pat: 0x55815ba4fa70
mail | Apr 30 13:56:02 mail postfix/smtpd[1556]: <
localhost[127.0.0.1]: QUIT
mail | Apr 30 13:56:02 mail postfix/smtpd[1556]: >
localhost[127.0.0.1]: 221 2.0.0 Bye
Czyli wartość nagłówka "Return-Path" jest rozdzielana na dwie oddzielne
instrukcje. O ile się nie mylę, przełamanie wartości nagłówka działa
przynajmniej częściowo zgodnie z zaleceniem z RFC 2822. Oczywiście nie
"usprawiedliwia" to podziału wartości na dwie instrukcje.
Czy ma ktoś pomysł, gdzie szukać dalej?
Jest to błąd w konfiguracji po mojej stronie, czy też po stronie serwera
pocztowego "pośrednika"?
Przesyłając tego typu wiadomości bezpośrednio na konto na moim serwerze
nie dochodzi do podziału wartości nagłówków, więc nie raczej nie jest to
wina nadawcy wiadomości.
Zgłębiam temat już dłuższy czas, ale w tym miejscu utknąłem.
Pozdrawiam,
q0o
Re: Postfix/smtpd i fetchmail - bład 501 związany z "CR LF spacja" w wartości nagłówka "Return-Path"
Author: PawelS pawel(at)wbcd(dot)pl
Date: Mon, 18 May 2020 17:36
Date: Mon, 18 May 2020 17:36
75 lines
4793 bytes
4793 bytes
q0o pisze:
> Witam,
> Jako, że z e-maili korzystam na co dzień (a lubię wiedzieć jak działają
> technologie, z którym korzystam), postanowiłem zobaczyć, jak to wygląda
> od drugiej strony i założyć własny serwer pocztowy.
>
> Jakiś czas temu zająłem się kwestią fetchmaila, z którego korzystam, aby
> móc pobierać wiadomości z zewnętrznych skrzynek pocztowych na lokalne
> konto, zlokalizowane na moim serwerze. Natknąłem się jednak na problem z
> pobieraniem niektórych e-maili, pochodzących z raczej szeroko znanych
> usług (więc - jak przypuszczam - z działających prawidłowo serwerów
> pocztowych).
>
> Przy dostarczaniu wspomnianych wiadomości z fetchmaila zwracany jest
> błąd "501 5.1.7 Bad sender address syntax".
>
> Analizując nagłówki tego typu "problematycznych" wiadomości powtarza
> jedna kwestia - posiadają one w wartości nagłówka "Return-Path", po 2
> znakach nowej linii (CR LF) dodatkową spację, przykładowo:
> ...
> Return-Path:
> <01000171e5ba5a76-8fcd01c1-f182-4d95-985d-bfdde77d05eb-000000@m
>
> ail.crowdin.com>
> ...
> Czyli szesnastkowo (końcówka wartości, problematyczne znaki zaznaczyłem
> nawiasami klamrowymi {}):
> 30 30 40 6D{0D 0A 20}61 69 6C 2E 63 72 6F 77 64 69 6E 2E 63 6F 6D 3E
> 0 0 @ m CR LF a i l . c r o w d i n . c o m >
>
[...]
>
> Czyli wartość nagłówka "Return-Path" jest rozdzielana na dwie oddzielne
> instrukcje. O ile się nie mylę, przełamanie wartości nagłówka działa
> przynajmniej częściowo zgodnie z zaleceniem z RFC 2822. Oczywiście nie
> "usprawiedliwia" to podziału wartości na dwie instrukcje.
>
> Czy ma ktoś pomysł, gdzie szukać dalej?
> Jest to błąd w konfiguracji po mojej stronie, czy też po stronie serwera
> pocztowego "pośrednika"?
Stety, niestety to będzie błąd "po mojej stronie",
w sensie używanie takiego a nie innego oprogramowania.
Swoją drogą nie wiedząc o istnieniu takiego fetchmail
sam napisałem coś podobnego: imap2smtp.pl,
który też pobiera wiadomości poprzez IMAP a wysyła do SMTP.
> Przesyłając tego typu wiadomości bezpośrednio na konto na moim serwerze
> nie dochodzi do podziału wartości nagłówków, więc nie raczej nie jest to
> wina nadawcy wiadomości.
> Zgłębiam temat już dłuższy czas, ale w tym miejscu utknąłem.
Niestety dokumentacja fetchmail nie jest zbyt czytelna,
ale być może poniższe opcje mogą być pomocne:
-n | --norewrite
-E <line> | --envelope <line>
(Keyword: envelope; Multidrop only)
In the configuration file, an enhanced syntax is used:
envelope [<count>] <line>
This option changes the header fetchmail assumes will carry
a copy of the mail's envelope address. Normally this is 'X-Envelope-To', but
as this header is not standard, practice varies. See the
discussion of multidrop address handling below. As a special
case, 'envelope "Received"' enables parsing of sendmail-style Received lines.
This is the default, and it should not be necessary
unless you have globally disabled Received parsing with 'no
envelope' in the .fetchmailrc file.
Niestety przy próbie wpisania "envelope" do pliku .fetchmailrc
lub nawet "no envelope" traktuje to od razu jako błąd,
a przykład pokazuje jednoznacznie jak taka linia powinna zostać zapisana:
fetchmail:/home/user/.fetchmailrc:1: syntax error at envelope
fetchmail:/home/user/.fetchmailrc:2: syntax error at no
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads