🚀 go-pugleaf

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