Krzysztof Halasa wrote:

> arekmx <a...@g...pl> writes:
>
>> knode wyświetla nieciekawie. Zdaje się gdyby było w nagłówkach
>> content-disposition: inline to by wyświetlał po ludzku.
>
> Przy text/plain widzi mu sie cos innego domyslnie? :-)

Dokładnie (jeśli jest multipart). Wyświetla co prawda tekst ale w ramkach (a
tym samym wychodzą pooddzielane fragmenty tekstu). AFAIK rfc wspomina
o "inline" do celów wyświetlania dokładnie tam gdzie dany fragment siedzi.
Popraw czytnik ;-P

--
Arek, arekmx|gazeta.pl

do góry

arekmx <a...@g...pl> writes:

> AFAIK rfc wspomina
> o "inline" do celów wyświetlania dokładnie tam gdzie dany fragment siedzi.

Jakos nie widze, dokladniejszy namiar?
--
Krzysztof Halasa

do góry

Krzysztof Halasa wrote:

> arekmx <a...@g...pl> writes:
>
>> AFAIK rfc wspomina
>> o "inline" do celów wyświetlania dokładnie tam gdzie dany fragment
>> siedzi.
>
> Jakos nie widze, dokladniejszy namiar?

rfc2183, 2.1

--
Arek, arekmx|gazeta.pl

do góry

arekmx <a...@g...pl> writes:

>>> AFAIK rfc wspomina
>>> o "inline" do celów wyświetlania dokładnie tam gdzie dany fragment
>>> siedzi.
>>
>> Jakos nie widze, dokladniejszy namiar?
>
> rfc2183, 2.1

... mowi, ze bez "inline" czytnik moze wyswietlic jakas czesc
zarowno jako "inline", a takze jako "attachment".

Widzial ktos czytnik, ktory wyswietla text/plain (bez podanego
"Content-Disposition: attachment") jako attachment? Obawiam sie,
ze osobne wyswietlanie fragmentow text/plain to nie jest
traktowanie ich jako zalacznik, a po prostu wadliwe wyswietlanie.

Natomiast, co bardziej istotne, RFC 2046 5.5.1 mowi:
NOTE: The CRLF preceding the boundary delimiter line is conceptually
attached to the boundary so that it is possible to have a part that
does not end with a CRLF (line break). Body parts that must be
considered to end with line breaks, therefore, must have two CRLFs
preceding the boundary delimiter line, the first of which is part of
the preceding body part, and the second of which is part of the
encapsulation boundary.

A wiec:
a) bledne jest lamanie linii na granicy czesci
b) wyswietlanie informacji o zestawie znakow w tekscie takze
jest oczywiscie bledne.

Jedynym "usprawiedliwieniem" takiego wadliwego zachowania jest
to, ze malo czytnikow generuje takie listy, i ze robia to tylko
w specyficznych sytuacjach (takich jak ta, gdzie mozliwe jest
niejednoznaczne przekodowanie z UTF-8 do ISO 8859).
--
Krzysztof Halasa

do góry

Mirosław Jaworski <m...@i...pl> wrote:
> Potrafię sobie wyobrazić kilkanaście godzin opóźnienie kiedy
> implementujący greylisting de facto whitelistuje po którymś tam
> wznowieniu [...] Takie postępowanie jest idiotyczne.
> Poza tym - kto otwiera okienko czasowe na wznowienie, które ma
> zwhitelistować serwer nadawczy, na czas kilkunastu godzin? Idiotyzm nr 2.
> Podziękuj projektantom takiego klastra, którzy nie umieją zrobić
> greylistingu dla klastra. To oczywiste, że wznowienie ma wszelkie
> prawo próbować przejść sesją do innego node'a klastra. To jest źle
> zaimplementowany greylisting.
> Prawidłowo zaimplementowany greylisting niewiele obciąży serwer nadawczy
> - jednym dodatkowy mailem na kilka dni. [...]
> Greylisting musi umieć rozpoznawać prawdziwe wznawianie od udawanego,
> którego niektórzy spamerzy się nauczyli.

No już tyle napisałeś, jak to istniejące implementacje są złe, to teraz
napisz, jaką dokładnie sam masz.

p.

--
Beware of he who would deny you access to information, for in his
heart he dreams himself your master. -- Commissioner Pravin Lal

do góry