Re: [exim-dev] Refactor optional MAIL args processing

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: Todd Lyons
Dátum:  
Címzett: Jeremy Harris, exim-dev
Új témák: Re: [exim-dev] Refactor optional MAIL args processing
Tárgy: Re: [exim-dev] Refactor optional MAIL args processing
On Fri, Apr 13, 2012 at 7:44 AM, Todd Lyons <tlyons@???> wrote:
> On Thu, Apr 12, 2012 at 7:38 PM, Phil Pennock <pdp@???> wrote:
>>> > I did some testing and every other MTA I can find accepts a TAB as a valid
>>> > separator, exim seems to be the only one who doesn't allow it.  A quick fix
>>> > doesn't appear to be too intrusive, but there may be better ways of solving
>>> > it.  This is in the extract_option() function.  The line numbers will be
>>> > off since I have some other modifications in this file:
>> Went for a minor variation, using isspace(); the only bad character
> Understood.  Passes my testing now.  Thanks Phil!


Interesting, an overnight packet dump revealed that it sometimes isn't
a tab. In the one below, it is a space. The cause is that more than
one optional parameter is being passed. It works properly on standard
exim 4.77, but with my refactoring patch, it does not. I'll bet I
don't reset the state variable of the options processing (reversed the
order of BODY= and SIZE= and it works ok).

T 219.87.80.49:3880 -> 208.89.138.22:25 [AP]
  4d 41 49 4c 20 46 52 4f    4d 3a 3c 50 65 67 67 79    MAIL FROM:<Peggy
  5f 58 69 65 40 73 64 63    2e 73 65 72 63 6f 6d 6d    _Xie@???
  2e 63 6f 6d 3e 20 42 4f    44 59 3d 38 42 49 54 4d    .com> BODY=8BITM
  49 4d 45 20 53 49 5a 45    3d 32 38 34 38 0d 0a 52    IME SIZE=2848..R
  43 50 54 20 54 4f 3a 3c    72 6f 62 65 72 74 40 65    CPT TO:<robert@e
  76 65 72 63 61 6d 65 6c    2e 63 6f 6d 2e 74 77 3e    vercamel.com.tw>
  0d 0a 52 43 50 54 20 54    4f 3a 3c 6b 69 6b 69 40    ..RCPT TO:<kiki@
  65 76 65 72 63 61 6d 65    6c 2e 63 6f 6d 2e 74 77    evercamel.com.tw
  3e 0d 0a 44 41 54 41 0d    0a                         >..DATA..



T 208.89.138.22:25 -> 219.87.80.49:3880 [AP]
  35 30 31 20 3c 50 65 67    67 79 5f 58 69 65 40 73    501 <Peggy_Xie@s
  64 63 2e 73 65 72 63 6f    6d 6d 2e 63 6f 6d 3e 20    dc.sercomm.com>
  42 4f 44 59 3d 38 42 49    54 4d 49 4d 45 3a 20 6d    BODY=8BITMIME: m
  61 6c 66 6f 72 6d 65 64    20 61 64 64 72 65 73 73    alformed address
  3a 20 42 4f 44 59 3d 38    42 49 54 4d 49 4d 45 20    : BODY=8BITMIME
  6d 61 79 20 6e 6f 74 20    66 6f 6c 6c 6f 77 20 3c    may not follow <
  50 65 67 67 79 5f 58 69    65 40 73 64 63 2e 73 65    Peggy_Xie@???
  72 63 6f 6d 6d 2e 63 6f    6d 3e 20 0d 0a 35 30 33    rcomm.com> ..503
  20 73 65 6e 64 65 72 20    6e 6f 74 20 79 65 74 20     sender not yet
  67 69 76 65 6e 0d 0a 35    30 33 20 73 65 6e 64 65    given..503 sende
  72 20 6e 6f 74 20 79 65    74 20 67 69 76 65 6e 0d    r not yet given.
  0a 35 30 33 2d 41 6c 6c    20 52 43 50 54 20 63 6f    .503-All RCPT co
  6d 6d 61 6e 64 73 20 77    65 72 65 20 72 65 6a 65    mmands were reje
  63 74 65 64 20 77 69 74    68 20 74 68 69 73 20 65    cted with this e
  72 72 6f 72 3a 0d 0a 35    30 33 2d 35 30 33 20 73    rror:..503-503 s
  65 6e 64 65 72 20 6e 6f    74 20 79 65 74 20 67 69    ender not yet gi
  76 65 6e 0d 0a 35 30 33    20 56 61 6c 69 64 20 52    ven..503 Valid R
  43 50 54 20 63 6f 6d 6d    61 6e 64 20 6d 75 73 74    CPT command must
  20 70 72 65 63 65 64 65    20 44 41 54 41 0d 0a        precede DATA..



Just wanted to point out that my previous refactoring patch still was
not working properly.

...Todd
--
Always code as if the guy who ends up maintaining your code will be a
violent psychopath who knows where you live. -- Martin Golding